Tom Lane wrote:
ISTM we could fix that by extending the index VACUUM interface to
include two concepts: aside from "remove these TIDs when you find them",
there could be "replace these TIDs with those TIDs when you find them".
This would allow pointer-swinging to one of the child tuples, after
which the old root could be removed.

Implementing the "replace these TIDs" operation atomically would be simple, except for the new bitmap index am. It should be possible there as well, but if the old and new tid happen to be on a different bitmap page, it requires some care to avoid deadlocks.

Also, we'd need more work mem for vacuum.

This has got the same atomicity
problem as for CREATE INDEX, because it's the same thing: you're
de-HOT-ifying the child.

Not exactly. De-HOT-ifying, or chilling, a child means inserting new index entries. But if we're just replacing the tids from the existing index entries, it's ok if we crash after replacing some but not all of them. The next vacuum would replace the rest of the pointers, and remove the old root tuple.

  Heikki Linnakangas

---------------------------(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

Reply via email to