From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Make HeapTupleSatisfiesMVCC more concurrent |
Date: | 2015-08-19 15:21:01 |
Message-ID: | 1001.1439997661@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Shulgin, Oleksandr | 2015-08-19 15:25:07 | Re: Proposal: Implement failover on libpq connect level. |
Previous Message | Tatsuo Ishii | 2015-08-19 15:17:35 | Re: Proposal: Implement failover on libpq connect level. |