On 19 August 2015 at 00:49, Tom Lane <t...@sss.pgh.pa.us> wrote: > Jeff Janes <jeff.ja...@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...@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
