Alvaro Herrera <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])