Re: Brain dump: btree collapsing

Manfred Koizar <mkoi-pg(at)aon(dot)at> 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