Re: Single Index Tuple Chain (SITC) method

On Thu, Jun 29, 2006 at 01:39:51AM +0300, Hannu Krosing wrote:
> And anyway, ctid is a usable unique row identifier only within read-only
> transactions, or not ?

Err, no. The ctid is the only identifer of a tuple in any case. When
you do a delete, the tuple to be deleted is indicated by the ctid field
which has been passed up from the base table through the rest of the
query. When you reach the top the ctid better refer to the same tuple
or you'll delete the wrong one. UPDATE is the same.

In READ COMMITTED mode, the tuple is rechecked for visibility and if
it's invisible, the ctid chain is followed to find the visible one
(which may not necessarily be the last one).

For all intents and purposes, the CTID of tuple can't change unless
you're 100% certain no-one is using it in any way. That's what the
vacuum lock is for.

> Is it correct to assume, that only one row version can be in process of
> being modified at any one time?

No, different transactions may be updating differing versions, depending
on what was visible at the time. In serialisable transactions you'll
get a serialisation failure though, and for read committed, the query
will be rerun for the latest version of the tuple.

One thing I am confused about, currently the ctid chain follows tuple
history so that transactions can find the latest version of any tuple,
even if the key fields have changed. This proposal breaks that, I'm not
sure how important that is though.

> Tom - what do you think of the other related idea, that of reusing dead
> index entries ?

I'd like to know about this too, including ideas about truncating
tuples to just the header.

Have a nice day.
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.