Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Ah, right, I missed the connection. Hmm ... that's sort of the inverse
>> of the "killed tuple" optimization we put in a release or two back,
>> where an index tuple is marked as definitely dead once it's committed
>> dead and the deletion is older than all active transactions.
> Yes, it is sort of the reverse, but how do you get around the delete
> case?
A would-be deleter of a tuple would have to go and clear the "known
good" bits on all the tuple's index entries before it could commit.
This would bring the tuple back into the "uncertain status" condition
where backends would have to visit the heap to find out what's up.
Eventually the state would become certain again (either dead to
everyone or live to everyone) and one or the other hint bit could be
set again.
The ugly part of this is that clearing the bit is not like setting a
hint bit, ie it's not okay if we lose that change. Therefore, each
bit-clearing would have to be WAL-logged. This is a big part of my
concern about the cost.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
