Re: Make HeapTupleSatisfiesMVCC more concurrent

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Make HeapTupleSatisfiesMVCC more concurrent
Date: 2015-08-19 20:07:59
Message-ID: CAMkU=1x-eQQ3D+h3SGhEE_YGNe-=ttB=F-j-A1H9gFG29ug4hA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 18, 2015 at 5:36 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2015-08-19 20:08:34 Re: Our trial to TPC-DS but optimizer made unreasonable plan
Previous Message Marc Mamin 2015-08-19 19:55:45 Re: Declarative partitioning