"Luca Ferrari" <fluca1978@infinito.it> writes:
> Thanks fot these details. Now a few other questions come into my mind (I hope
> not to bother you guys!).
>
> In chapter 49 of the documentation (index access) I read that an index stores
> pointers to any version of the tuple that is present in the database. Now I
> remember that the t_ctid field of the HeapTupleHeaderData points to the newer
> versione of a tuple (if exists) and that it is possible to follow the t_ctid
> to get the newer tuple version. Now since a new version tuple is stored at
> the end of a table, chances are that the tuple is stored into another page
> that the older one. If this is right, the index is required to know exactly
> in which page a tuple version is, rather then following the t_ctid link, thus
> what is the purpose of such chain?
You're right, the index contains pointers to *every* version of the tuple. So
in a regular SELECT statement you don't need to look at the update chain at
all.
The main use of the update chain is when you want to perform an UPDATE or
DELETE. In that case when you come across a record which is being updated by
another transaction you must wait until that other transaction finishes and
then update the resulting record (if you're in read-committed mode).
> The second question is why the index returns all the tuple version without
> considering time (I guess MVCC) constraints? What are the problems of
> evaluationg the xmin,xmax stuff within the index amget methods? Maybe this is
> not done due to concurrency issues?
The xmin,xmax stuff isn't in the index. So that would require that the index
amget methods read the heap. That would just mean moving the code from one
place to another but still doing the same amount of work. In fact in many
cases we can combine multiple indexes to eliminate records before we have to
read the heap so it would mean doing redundant visibility checks and doing so
on records we might have been able to eliminate first.
> Third, I read about not valid MVCC snapshots (e.g., SnapshotNow). What is the
> meaning of such "strange" snapshots? Because postgresql should always
> guarantee at least read committed isolation, and thus this should be done
> thru MVCC.....
They're needed for things like the above UPDATE chain following, catalog
checks (generally you can use an index or table which has been committed even
if it was committed after you started your transaction), relational integrity
checks, and other special cases like those.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
