[HACKERS] t_ctid chains

2005-08-18 Thread Paul Tillotson 
(Prompted by nearby thread about VACUUM FULL bugs, but not having 
anything to do with that properly speaking.)


Hackers,

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. 

I infer that the there must be some sort of optimization to make it 
worth (a) using extra space in the disk pages and (b) causing the extra 
complexity such as the bugs mentioned in VACUUM FULL.


So: what are the t_ctid chains good for?  If this is too long or too 
elementary to type, can someone point me to the source code that uses 
t_ctid chains? 


Regards,
Paul Tillotson

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] t_ctid chains

2005-08-18 Thread Tom Lane 
Paul Tillotson [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org