On Sun, 16 Jan 2005 20:49:45 +0100, Manfred Koizar wrote: > On Thu, 13 Jan 2005 00:39:56 -0500, Tom Lane wrote: >> 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. > > Last time we discussed this, didn't we come to the conclusion, that > resetting status bits is not a good idea because of possible race > conditions?
http://archives.postgresql.org/pgsql-performance/2004-05/msg00004.php > In a previous post you wrote: > | I think we still have one free bit in index tuple headers... > > AFAICS we'd need two new bits: "visible to all" and "maybe dead". > > Writing the three status bits in the order "visible to all", "maybe > dead", "known dead", a normal index tuple lifecycle would be > > 000 -> 100 -> 110 -> 111 > > In states 000 and 110 the heap tuple has to be read to determine > visibility. > > The transitions 000 -> 100 and 110 -> 111 happen as side effects of > index scans. 100 -> 110 has to be done by the deleting transaction. > This is the operation where the additional run time cost lies. > > One weakness of this approach is that once the index tuple state is > 110 but the deleting transaction is aborted there is no easy way to > reset the "maybe deleted" bit. So we'd have to consult the heap for > the rest of the tuple's lifetime. How bad is that really with a typical workload? Jochem ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
