Heikki Linnakangas wrote:
One potential issue I'm seeing is that if we rely on the unbroken chain starting from < OldestXmin, and that tuple isn't there because of a bug, for example, the later version of the tuple is skipped and the row is lost.
After further thought, I don't feel comfortable with the idea because of the above loss of robustness.
I'm thinking of keeping an in-memory mapping of old and new tids of updated tuples while clustering, instead. That means that cluster requires a little bit of memory for each RECENTLY_DEAD updated tuple. In the worst case that means that you run out of memory if there's too many of those in the table, but I doubt that's going to be a problem in practice.
-- Heikki Linnakangas 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
