From: Andres Freund <andres@2ndquadrant.com>
To: Jeff Janes <jeff.janes@gmail.com>
Cc: Josh Berkus <josh@agliodbs.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
Date: Wed, 25 Sep 2013 20:43:30 +0200
Message-ID: <20130925184330.GC5578@awork2.anarazel.de> (raw)
In-Reply-To: <CAMkU=1yy-YEQVvqj2xJitT1EFkyuFk7uTV_hrOMGyGMxpU=N+Q@mail.gmail.com>
References: <CAC6=Lj7fYUWzcKLU6X7-8D1q+ijvBrGmwS2dw4mixhH8F8KSAw@mail.gmail.com>
<CAMkU=1wjnoFOrzVqLpUg2Ja=+kd_sv2HP4+cF-Y7r4a3uHT-tg@mail.gmail.com>
<1379944816.30390.YahooMailNeo@web162903.mail.bf1.yahoo.com>
<5815.1380018947@sss.pgh.pa.us>
<e8795f5e292a0bd1a4d8ebbcb54e4a98.squirrel@shrek.krogh.cc>
<WM!41fcd3fa079d542735fe69d3254859689c1085f7c897fa6e9a9b828ad9d2c80ba7b6b2c4c67c942a6115262993147370!@asav-1.01.com>
<5241CF2A.2070309@agliodbs.com>
<CAMkU=1ys-fB2Nczt=LT1pVHzK3Jv4Jb-67N29Gzyx3nraweoZQ@mail.gmail.com>
<20130925175312.GB5578@awork2.anarazel.de>
<CAMkU=1yy-YEQVvqj2xJitT1EFkyuFk7uTV_hrOMGyGMxpU=N+Q@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
On 2013-09-25 11:17:51 -0700, Jeff Janes wrote:
> On Wed, Sep 25, 2013 at 10:53 AM, Andres Freund <andres@2ndquadrant.com>wrote:
>
> > On 2013-09-25 00:06:06 -0700, Jeff Janes wrote:
> > > > On 09/20/2013 03:01 PM, Jeff Janes wrote:> 3) Even worse, asking if a
> > > > given transaction has finished yet can be a
> > > > > serious point of system-wide contention, because it takes the
> > > > > ProcArrayLock, once per row which needs to be checked. So you have
> > 20
> > > > > processes all fighting over the ProcArrayLock, each doing so 1000
> > > > times per
> > > > > query.
> >
> > That should be gone in master, we don't use SnapshotNow anymore which
> > had those TransactionIdIsInProgress() calls you're probably referring
> > to. The lookups discussed in this thread now use the statement's
> > snapshot. And all those have their own copy of the currently running
> > transactions.
> See HeapTupleSatisfiesMVCC, near line 943 of tqual.c:
>
> else if (TransactionIdIsInProgress(HeapTupleHeaderGetXmin(tuple)))
> return false;
> else if (TransactionIdDidCommit(HeapTupleHeaderGetXmin(tuple)))
> SetHintBits(tuple, buffer, HEAP_XMIN_COMMITTED,
> HeapTupleHeaderGetXmin(tuple));
>
Hm, sorry, misrembered things a bit there.
> If we guarded that check by moving up line 961 to before 943:
>
> if (XidInMVCCSnapshot(HeapTupleHeaderGetXmin(tuple), snapshot))
> return false; /* treat as still in progress */
>
> Then we could avoid the contention, as that check only refers to local
> memory.
That wouldn't be correct afaics - the current TransactionIdIsInProgress
callsite is only called when no HEAP_XMIN_COMMITTED was set. So you
would have to duplicate it.
> As far as I can tell, the only downside of doing that is that, since hint
> bits might be set later, it is possible some dirty pages will get written
> unhinted and then re-dirtied by the hint bit setting, when more aggressive
> setting would have only one combined dirty write instead. But that seems
> rather hypothetical, and if it really is a problem we should probably
> tackle it directly rather than by barring other optimizations.
I am - as evidenced - too tired to think about this properly, but I
think you might be right here.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: andres@2ndquadrant.com, jeff.janes@gmail.com, josh@agliodbs.com
Subject: Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
In-Reply-To: <20130925184330.GC5578@awork2.anarazel.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox