Re: Btree Index on PostgreSQL and Wiredtiger (MongoDB3.2) - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: Btree Index on PostgreSQL and Wiredtiger (MongoDB3.2)
Date
Msg-id 87oa4xmss7.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: Btree Index on PostgreSQL and Wiredtiger (MongoDB3.2)  (Greg Stark <stark@mit.edu>)
Responses Re: Btree Index on PostgreSQL and Wiredtiger (MongoDB3.2)  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
>>>>> "Greg" == Greg Stark <stark@mit.edu> writes:
>> No, because as the pages split, they fill more slowly (because there>> are now more pages). So on average in a large
randomlyfilled index,>> pages spend more time nearer 50% full than 100% full. This is easy>> to demonstrate by creating
atable with an indexed float8 column and>> adding batches of random() values to it, checking with pgstatindex>> at
intervals- the average leaf density will rarely exceed 70%.>> >> However, worst case conditions can give lower leaf
densities;>>obviously the worst case is if the data is loaded in an order and>> quantity that just happens to leave
everyleaf page recently split.
 
Greg> btree pages don't split 50/50 either. They split biased to assumeGreg> the greater side of the split will receive
moreinserts -- iircGreg> 70/30.
 

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.)

-- 
Andrew (irc:RhodiumToad)



pgsql-hackers by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: No longer possible to query catalogs for index capabilities?
Next
From: Greg Stark
Date:
Subject: Re: Btree Index on PostgreSQL and Wiredtiger (MongoDB3.2)