On Fri, Sep 12, 2014 at 5:42 PM, Heikki Linnakangas <hlinnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
