Alvaro Herrera <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> That has nothing to do with it, because the space isn't actually free >> for re-use until vacuum deletes the tuple.
> I think the idea is a different "free space map" of sorts, whereby a > transaction that obsoletes a tuple puts its block number in that map. A > transaction that inserts a new tuple goes to the FSM. If nothing is > found, it then goes to the new map. A block returned from that map is > then scanned and any tuple that's no longer visible for anyone is > reused. I thought we had sufficiently destroyed that "reuse a tuple" meme yesterday. You can't do that: there are too many aspects of the system design that are predicated on the assumption that dead tuples do not come back to life. You have to do the full vacuuming bit (index entry removal, super-exclusive page locking, etc) before you can remove a dead tuple. > Essentially, we would be folding the "find > dead tuples and compress page" logic, which is currently in vacuum, back > to insert. IMHO this is unacceptable from a performance PoV. That's the other problem: it's not apparent why pushing work from vacuum back into foreground processing is a good idea. Especially not why retail vacuuming of individual tuples will be better than wholesale. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly