Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> Even if you could track the tuple's committed-good status reliably,
> >> that isn't enough under MVCC.
>
> > I mentioned that:
>
> >> (Oh, and you could only update the bit when all active transactions
> >> are newer than the creation transaction so we know they should all see
> >> it as visible.)
>
> 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. Maybe that
> would work. You'd still have to visit the heap when a tuple is in the
> "uncertain" states, but with luck that'd be only a small fraction of the
> time.
Yes, it is sort of the reverse, but how do you get around the delete
case? Even if the bit is set, how do you know it wasn't deleted since
you set the bit? Seems you always have to still check the heap, no?
> I'm still concerned about the update costs of maintaining these bits,
> but this would at least escape the index-bloat objection. I think we
> still have one free bit in index tuple headers...
You mean you are considering clearing the index bit when you delete the
row?
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073