"Gokulakannan Somasundaram" <[EMAIL PROTECTED]> writes: >> Another reason is that it avoids the whole problem of updating multiple >> pages atomically, without deadlocks. > > > Thanks Heikki. I am still not getting what you said. In the case of HOT, > you need to update the top pointer to point to some other tuple in some > other page. That's one update. what's the other one?
There are several problems, two that come to mind are: 1) How do you make the dead top pointer redirect to the first live pointer in the chain? Currently we store the item number of the first live tuple in the line pointer. You would have to keep the tuple around, though you could truncate it to just the tuple header. 2) When vacuuming how do you find the head of the chain when you're looking at a dead tuple? There's no space in the tuple header to store the head of the chain. Besides you want to vacuum scanning sequentially, not randomly. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning ---------------------------(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
