Manfred Koizar <[EMAIL PROTECTED]> writes: > Given that we have a mostly empty metapage per index, and the metapage > is in memory most of the time, using it for the freelist looks almost > like a free lunch.
No, because of locking. Every time you write-lock the metapage to add or remove freelist entries, you are denying all other processes the ability to start an index scan. Check the btree literature --- exclusive locks near the root of the tree are death for concurrent performance, and must be avoided as much as possible. If I were planning to use a freelist I would keep it in a different page so as not to need to lock the metapage for freelist manipulations. But I don't see the value of having one at all. It just adds that much more disk traffic (and WAL traffic) for each page split or merge. There are also atomicity concerns --- is addition/removal of a freelist entry an atomic part of the page merge or split operation, or is it a separate atomic operation with its own WAL record? If the former, you have deadlocking problems; if the latter, post-crash-consistency problems. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])