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

From Jeff Janes
Subject Re: Make HeapTupleSatisfiesMVCC more concurrent
Date
Msg-id CAMkU=1x-eQQ3D+h3SGhEE_YGNe-=ttB=F-j-A1H9gFG29ug4hA@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 Tue, Aug 18, 2015 at 5:36 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I wrote:
> Just thinking about this ... I wonder why we need to call
> TransactionIdIsInProgress() at all rather than believing the answer from
> the snapshot?  Under what circumstances could TransactionIdIsInProgress()
> return true where XidInMVCCSnapshot() had not?

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().
The asserts did not fire in the standard regression tests nor in a
pgbench run, which is surely not proof of anything but it suggests
that I'm not totally nuts.

I wouldn't commit the changes in XidInMVCCSnapshot for real, but
otherwise this is a possibly committable patch.

This gives the same performance improvement as the original patch (when compiled without cassert).

It has survived testing in a hostile environment (rapid fire stream of contentious updates intermixed with selects, with or without frequent crashes) without signs of missed or duplicated rows.

So, it looks good to me.

Cheers,

Jeff

pgsql-hackers by date:

Previous
From: Marc Mamin
Date:
Subject: Re: Declarative partitioning
Next
From: Josh Berkus
Date:
Subject: Re: Our trial to TPC-DS but optimizer made unreasonable plan