Re: Index tuple killing code committed - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Index tuple killing code committed
Date
Msg-id 21622.1022278146@sss.pgh.pa.us
Whole thread Raw
In response to Re: Index tuple killing code committed  (Joe Conway <mail@joeconway.com>)
List pgsql-hackers
Joe Conway <mail@joeconway.com> writes:
> This may qualify as a "way out there" idea, or more trouble than it's 
> worth, but what about a table option which provides a bitmap index of 
> tuple status -- i.e. tuple dead t/f. If available, a seqscan in between 
> vacuums could maybe gain some of the same efficiency.

Hmm.  I'm inclined to think that a separate bitmap index wouldn't be
worth the trouble.  Under most scenarios it'd just require extra I/O
and not buy much.

However ... we could potentially take over the LP_DELETED flag bit of
heap tuples for the same use as for index tuples: set it when the tuple
is known dead for all transactions.  This would save calling
HeapTupleSatisfiesSnapshot in the inner loop of heapgettup, while not
adding much expense for the normal case where the tuple's not dead.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: Index tuple killing code committed
Next
From: Joe Conway
Date:
Subject: Re: Redhat 7.3 time manipulation bug