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