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

From Tom Lane
Subject Re: Make HeapTupleSatisfiesMVCC more concurrent
Date
Msg-id 25537.1440175478@sss.pgh.pa.us
Whole thread Raw
In response to Re: Make HeapTupleSatisfiesMVCC more concurrent  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Aug 18, 2015 at 8:36 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I experimented with the attached patch, which replaces
>> HeapTupleSatisfiesMVCC's calls of TransactionIdIsInProgress with
>> XidInMVCCSnapshot, and then as a cross-check has all the "return false"
>> exits from XidInMVCCSnapshot assert !TransactionIdIsInProgress().

> Like Jeff's approach, this will set hint bits less aggressively.

Only very marginally so, though: we will not set a hint bit in the case
where the updating transaction has committed/aborted but it is still shown
as running by our snapshot.  As soon as a reader comes along with a
snapshot taken after the updater ended, that transaction will set the hint
bit.

Note that in the case where the updating transaction committed, setting
the hint bit early wouldn't save anything anyway, since we'd still need
to run XidInMVCCSnapshot().  It is true that if the updater aborted,
we could save cycles by hinting earlier; but I believe the general project
policy about such choices is not to optimize for the abort case.  Also
note that the cycles wasted will now be in XidInMVCCSnapshot(), not in
ProcArray access, so they won't be as much of a scalability problem.

> But it's worth thinking about, and at the least we should document in
> the commit message or the comments that this change has this effect.

Agreed, there is a tradeoff being made.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Piotr Stefaniak
Date:
Subject: A few cases of left shifting negative integers
Next
From: Tom Lane
Date:
Subject: Re: A few cases of left shifting negative integers