Re: Further open item (Was: Status of 7.2)

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

In response to

Browse pgsql-hackers by date

  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?