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
IBPhoenix.
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
