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

From Simon Riggs
Subject Re: Make HeapTupleSatisfiesMVCC more concurrent
Date
Msg-id CANP8+j+jytogNb8+j2E1OEQNpxEC5W8iR+4XtLgSPxLh=jiHKA@mail.gmail.com
Whole thread Raw
In response to Re: Make HeapTupleSatisfiesMVCC more concurrent  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 19 August 2015 at 16:21, Tom Lane <tgl@sss.pgh.pa.us> wrote:
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.

This is what I suggested upthread.  It's not a massive gain, but its cheap and a straightforward patch.

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: Proposal: Implement failover on libpq connect level.
Next
From: Magnus Hagander
Date:
Subject: Re: allowing wal_level change at run time