On Sat, Aug 13, 2016 at 1:18 AM, Andrew Gierth
<and...@tao11.riddles.org.uk> wrote:
> Hmm? The code in _bt_findsplitloc and _bt_checksplitloc doesn't seem to
> agree with this.
> (Inserting on the high leaf page is a special case, which is where the
> fillfactor logic kicks in; that's why sequentially filled indexes are
> (by default) 90% full rather than 100%. But other pages split into
> roughly equal halves.)

Hm, I was going from this lore. I didn't realize it was only for
inserts near the end of the index. That's cleverer than I realized.

commit 1663f3383849968415d29965ef9bfdf5aac4d358
Author: Tom Lane <t...@sss.pgh.pa.us>
Date:   Sat Sep 29 23:49:51 2001 +0000

    Tweak btree page split logic so that when splitting a page that is
    rightmost on its tree level, we split 2/3 to the left and 1/3 to the
    new right page, rather than the even split we use elsewhere.  The idea
    is that when faced with a steadily increasing series of inserted keys
    (such as sequence or timestamp values), we'll end up with a btree that's
    about 2/3ds full not 1/2 full, which is much closer to the desired
    steady-state load for a btree.  Per suggestion from Ann Harrison of


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to