Hannu Krosing <hannu@tm.ee> writes:
> I'd propose a memory-only (or heavily cached) structure of tuple death
> transaction
> ids for all transactions since the oldest live trx.
Seems like just a special-purpose reimplementation of disk pages sitting
in shared buffers. If you've got the memory to keep track of tuples
you've killed recently, then you've probably got the memory to hold the
pages they're in, so a redundant separate caching structure is not
obviously a win.
The possible win of marking index entries dead (once their tuple is
known dead for all transactions) is that it saves visiting disk pages
that have *not* been visited recently, and thus that aren't likely to
be hanging around in buffers.
OTOH there are a lot of potential problems, most notably that
is-the-tuple-dead-for-ALL-transactions is not the normal tuple time
qual check, and so it'd represent extra overhead in indexscans.
I'm also concerned about how to do it without introducing lots of
ugly interactions (maybe even deadlocks) between the index access
methods and the heap access code.
If concurrent vacuuming turns out to be cheap enough, just running
vacuum frequently might be a better answer than trying to push the
maintenance work into the main line of execution.
regards, tom lane
