From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Tille, Andreas" <TilleA(at)rki(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Subject: | Re: Further open item (Was: Status of 7.2) |
Date: | 2001-11-19 21:11:09 |
Message-ID: | 3BF9756D.3090805@tm.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>Hannu Krosing <hannu(at)tm(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2001-11-19 21:11:22 | Re: TOAST performance (was Re: [GENERAL] Delete Performance) |
Previous Message | Bruce Momjian | 2001-11-19 21:06:39 | Re: [HACKERS] bug or change in functionality in 7.2? |