Re: Btree Index on PostgreSQL and Wiredtiger (MongoDB3.2)
От | Andrew Gierth |
---|---|
Тема | Re: Btree Index on PostgreSQL and Wiredtiger (MongoDB3.2) |
Дата | |
Msg-id | 87oa4xmss7.fsf@news-spur.riddles.org.uk обсуждение исходный текст |
Ответ на | Re: Btree Index on PostgreSQL and Wiredtiger (MongoDB3.2) (Greg Stark <stark@mit.edu>) |
Ответы |
Re: Btree Index on PostgreSQL and Wiredtiger (MongoDB3.2)
|
Список | 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 по дате отправления: