Jeff Janes <jeff.janes@gmail.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.
regards, tom lane
