On Wed, Jun 6, 2012 at 5:41 PM, Jim Nasby <jim@nasby.net> wrote:
> On 5/30/12 4:42 PM, Ants Aasma wrote:
>>
>> I was thinking about what is the earliest time where we could set hint
>> bits. This would be just after the commit has been made visible.
>
>
> Except that's only true when there are no other transactions running. That's
> been one of the big sticking points about trying to proactively set hint
> bits; in a real system you're not going to gain very much unless you wait a
> while before setting them.
are you sure? the relevant code to set hint bit during tuple scan
looks like this:
else if (TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetXmin(tuple))) { if
(HeapTupleHeaderGetCmin(tuple)>= snapshot->curcid) return false; /* inserted after scan started */
if (tuple->t_infomask & HEAP_XMAX_INVALID) /* xid invalid */ return true;
if (tuple->t_infomask & HEAP_IS_LOCKED) /* not deleter */ return true;
Assert(!(tuple->t_infomask & HEAP_XMAX_IS_MULTI));
if (!TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetXmax(tuple))) { /* deleting
subtransactionmust have aborted */ SetHintBits(tuple, buffer, HEAP_XMAX_INVALID,
InvalidTransactionId); return true; }
if (HeapTupleHeaderGetCmax(tuple) >= snapshot->curcid) return true; /* deleted after scan started
*/ else return false; /* deleted before scan started */ } else if
(TransactionIdIsInProgress(HeapTupleHeaderGetXmin(tuple))) return false; else if
(TransactionIdDidCommit(HeapTupleHeaderGetXmin(tuple))) SetHintBits(tuple, buffer, HEAP_XMIN_COMMITTED,
HeapTupleHeaderGetXmin(tuple)); else { /* it must have aborted or crashed */
SetHintBits(tuple,buffer, HEAP_XMIN_INVALID, InvalidTransactionId); return false; }
The backend that commits the transaction knows that the transaction is
committed and that it's not in progress (at least from itself). Why
do you have to wait for other transactions in progress to finish?
Setting the xmin committed bit doesn't keep you from checking the xmax
based rules.
merlin