On Fri, 2007-02-09 at 13:47 -0500, Tom Lane wrote: > Hannu Krosing <[EMAIL PROTECTED]> writes: > > What are the problems with just shuffling the last (and only visible) > > tuple to replace the HOT-hain root and be done with it ? > > ctid stops being a reliable identifier.
Yes, that sums it up. The issue can be overcome in the internals, but the only means of doing so that seemed workable required changing the output of the CTID special column. Some applications use the tid datatype directly to relocate rows within a transaction using the tidscan. ODBC driver uses that concept to implement Updateable Cursors from the client. We can change that, but we'd break all the other ones we don't know about. This issue was one of the major contributing factors to the size of the previous HOT prototype, making it more invasive than is really desirable. Pointer-swinging avoids those issues and seems workable, even if it is a pain to have to visit the index during VACUUM. So changing CTID isn't a bridge we really need to cross, for which I'm glad. Just as a matter of record, the tuple identifier would need to include (block, itemid, xmin, cmin) to make this idea work, with the itemid being that of the root tuple and the xmin and cmin being the tuple in the chain that is being referenced. This would've then allowed callers to relocate a specific tuple, even when the update chain had changed between block accesses. Anyway, glad we're not going there anymore. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
