"Luca Ferrari" <fluca1978@xxxxxxxxxxx> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org/
