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

Reply via email to