Tom Lane wrote:
>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.
>
I suspect that for even the border case of a table containing just 1
CHAR(1) field the
above structure will be a lot smaller than the page cache for the same
tuples.
>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.
>
What I proposed would have been mostly the job of concurrent vacuum
(marking/removing dead index tuples)
Perhaps it would be an overall win for fast changing (vs. fast-growing)
databases if
we kept the tuple metainfo (attnum < 0) on separate (cache) pages, as it
saves writes of
tmax updates on both UPDATE and DELETE.
If we kept them in a separate table as well that could make the metainfo
"table"
essentially a kind of index. That table/index could of course be
concealed inside
the main table by using typed data pages.
---------------
Hannu