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