Re: Make HeapTupleSatisfiesMVCC more concurrent

On 19 August 2015 at 00:49, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> > When we check a tuple for MVCC, it has to pass checks that the inserting
> > transaction has committed, and that it committed before our snapshot
> > began. And similarly that the deleting transaction hasn't committed, or
> > did so after our snapshot.
>
> > XidInMVCCSnapshot is (or can be) very much cheaper
> > than TransactionIdIsInProgress, because the former touches only local
> > memory while the latter takes a highly contended lock and inspects shared
> > memory. We do the slow one first, but we could do the fast one first and
> > sometimes short-circuit the slow one. If the transaction is in our
> > snapshot, it doesn't matter if it is still in progress or not.
>
> > This was discussed back in 2013 (
> >
> http://www.postgresql.org/message-id/CAMkU=1yy-YEQVvqj2xJitT1EFkyuFk7uTV_hrOMGyGMxpU=N+Q@mail.gmail.com
> ),
> > and I wanted to revive it. The recent lwlock atomic changes haven't made
> > the problem irrelevant.
>
> > This patch swaps the order of the checks under some conditions.
>
> 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'm thinking maybe TransactionIdIsInProgress is only needed for non-MVCC
> snapshot types.
>

+1

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