From: | "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> |
---|---|
To: | "Hannu Krosing" <hannu(at)tm(dot)ee>, "Tille, Andreas" <TilleA(at)rki(dot)de> |
Cc: | "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "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 17:26:00 |
Message-ID: | 46C15C39FEB2C44BA555E356FBCD6FA41EB420@m0114.s-mxs.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> >>The underlying problem the user is seeing is how to _know_ an index
> >>tuple is valid without checking the heap,
> >>
> I'd propose a memory-only (or heavily cached) structure of tuple death
transaction
> ids for all transactions since the oldest live trx. And when that
oldest finishes then
> the tombstone marks for all tuples deleted between that and the new
oldest are moved to
> relevant indexes (or the index keys are deleted) by concurrent vacuum
> or similar process.
Andreas said, that his data is only loaded/changed in the night, thus
for his queries all tuples found in the index are actually live.
Every heap tuple lookup results in "tuple valid".
In his case a per table global "highest xid" in heapdata that can be
compared
against highest xid during last vacuum would probably be sufficient
(or a flag for "modified after last vacuum").
Of course per table globals are a major headache regarding concurrency,
but there would be other possible optimizations that could profit from
such
a structure, like rowcount ...
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Sergio Pili | 2001-11-19 17:38:26 | Re: WAS: [Fwd: PostgreSQL new commands proposal] |
Previous Message | Larry Rosenman | 2001-11-19 16:53:37 | Re: 7.2b2 "make check" failure on Red Hat Linux 7.2 |