Re: Make HeapTupleSatisfiesMVCC more concurrent - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Make HeapTupleSatisfiesMVCC more concurrent
Date
Msg-id 1001.1439997661@sss.pgh.pa.us
Whole thread Raw
In response to Re: Make HeapTupleSatisfiesMVCC more concurrent  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Make HeapTupleSatisfiesMVCC more concurrent  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
I wrote:
> Andres Freund <andres@anarazel.de> writes:
>> I'm not sure about it, but it might be worthwhile to add a
>> TransactionIdIsKnownCompleted() check before the more expensive parts of
>> XidInMVCCSnapshot(). Neither the array search nor, much more so, the
>> subtrans lookups are free.

> Hmmm... the comment for TransactionIdIsKnownCompleted says it's to
> short-circuit calls of TransactionIdIsInProgress, which we wouldn't be
> doing anymore.  Maybe it's useful anyway but I'm not convinced.

After further thought, the right way to implement the equivalent
optimization would be to add a couple of fields to struct Snapshot that
would cache the xid last checked against that snapshot and the outcome of
that check; this would be independent of TransactionIdIsKnownCompleted.
There would be no need to use that cache for xids below xmin or above
xmax, which would improve its chance of being applicable to in-doubt xids.

Not entirely sure it's worth doing, but if someone wants to do the
legwork, this would be an independent optimization possibility.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: Bug? ExecChooseHashTableSize() got assertion failed with crazy number of rows
Next
From: "Shulgin, Oleksandr"
Date:
Subject: Re: Proposal: Implement failover on libpq connect level.