Re: Make HeapTupleSatisfiesMVCC more concurrent

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Make HeapTupleSatisfiesMVCC more concurrent
Date: 2015-08-18 23:49:10
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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 (
> 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.

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Kouhei Kaigai 2015-08-18 23:56:47 Re: Bug? ExecChooseHashTableSize() got assertion failed with crazy number of rows
Previous Message Qingqing Zhou 2015-08-18 23:40:06 Re: Our trial to TPC-DS but optimizer made unreasonable plan