Alvaro Herrera <alvherre@commandprompt.com> 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
