Re: Suspicious check (src/backend/access/gin/gindatapage.c)
От | Michael Paquier |
---|---|
Тема | Re: Suspicious check (src/backend/access/gin/gindatapage.c) |
Дата | |
Msg-id | CAB7nPqSsc-piWmU_wY1TFXZ2CL-Cw-xuPZc7e5jPp9O5g+HxFA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Suspicious check (src/backend/access/gin/gindatapage.c) (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Список | pgsql-hackers |
On Fri, Sep 12, 2014 at 5:42 PM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: > 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. Actually gin is the only method that does not have this parameter, no? Then the following extra-processing would be enough I imagine: 1) Tune freespace using fillfactor when placing keys to leaf data page (dataPlaceToPageLeaf) 2) On split, instead of (BLCKSZ * 3) / 4, have the left leaf full at (BLCKSZ * fillfactor) / 100 Regards, -- Michael
В списке pgsql-hackers по дате отправления: