Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> Putting the freelist on FSM rather on the metapage still strikes me as
> kind of strange; I remember you said the metapage was not enough space
> for all the possible candidate pages, but the FSM is even more limited.
Well, on modern machines there should be no problem with making an FSM
with multiple-million page slots, of which an individual index might
claim many thousand slots at need. But you're right that a metapage
plus overflow pages could remember more free pages. The problem with
that approach is that (a) you incur more I/O --- not only index traffic,
but WAL traffic, if you want the storage to be reliable; and (b) you
incur more locking overhead. Write locks on the metapage are death for
concurrency because they'll block all incoming btree operations.
We might have been able to avoid (b) by putting the freelist head
somewhere else than the primary metapage --- it was only a false notion
of storage economy that led us to think the wasted space on the metapage
was an appropriate place for the freelist. But there's really no way
around (a).
Given that we're not keeping records of heap free space on disk, it
seemed to me to make sense not to keep records of index free space on
disk either. Better to have one mechanism and concentrate on making it
good than have two so-so mechanisms.
> The other is that now I am left without a graduate project :-(
Oops :-(. Well, there's plenty of stuff on the TODO list, not to
mention useful projects that haven't made it to the list.
regards, tom lane
