Re: t_ctid chains

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Paul Tillotson <spam1011(at)adelphia(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: t_ctid chains
Date: 2005-08-18 23:18:15
Message-ID: 12446.1124407095@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Paul Tillotson <spam1011(at)adelphia(dot)net> writes:
> For some time, I have wondered: what does postgres use "t_ctid chains"
> for? It seems like it is useful to find the "newer" version of a
> tuple. However, wouldn't that eventually get found anyway? A
> sequential scan scans the whole table, and so it will find the new
> tuple. Since indexes contain all tuples, so will an index scan.

The problem is not that the table reader wouldn't "find" the tuple.
The problem is that he'd disregard it as too new for his snapshot.
The essential point of the EvalPlanQual mechanism is to identify tuples
that we should consider visible for modification even though the MVCC
rules say no. Basically, the normal search mechanisms will find a
prior state of the row (whichever state was committed when we took our
snapshot) and then we have to "chain up" to the latest state by
following the t_ctid links.

There's some discussion of this in the manual under
http://developer.postgresql.org/docs/postgres/transaction-iso.html#XACT-READ-COMMITTED

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chuck McDevitt 2005-08-18 23:35:58 Re: Windows + IP6 progress
Previous Message Chuck McDevitt 2005-08-18 23:11:31 Re: Windows + IP6 progress