| From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
|---|---|
| To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Gaetano Mendola <mendola(at)gmail(dot)com> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Suspicious check (src/backend/access/gin/gindatapage.c) |
| Date: | 2014-09-12 08:42:39 |
| Message-ID: | 5412B1FF.4000306@vmware.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 09/12/2014 11:38 AM, Heikki Linnakangas wrote:
> Now that the logic is fixed, I hope we
> won't get complaints that the indexes are bigger, if you fill a table by
> appending to the end. I wonder if we should aim at an even more uneven
> split; the default fillfactor for B-trees is 90%, for example. I didn't
> go that high when I wrote that, because the code in previous versions
> always did a 50/50 split. But it could be argued that a higher
> fillfactor makes sense for a GIN index - they typically don't get as
> much random updates as a B-tree.
Actually, we should add a fillfactor reloption to GIN. But that's 9.5
material.
- Heikki
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2014-09-12 09:03:53 | Re: pg_basebackup vs. Windows and tablespaces |
| Previous Message | Heikki Linnakangas | 2014-09-12 08:38:40 | Re: Suspicious check (src/backend/access/gin/gindatapage.c) |