From: Josh Berkus <josh@agliodbs.com>
To: pgsql-performance@postgresql.org
Subject: Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
Date: Tue, 24 Sep 2013 10:43:06 -0700
Message-ID: <5241CF2A.2070309@agliodbs.com> (raw)
In-Reply-To: <WM!41fcd3fa079d542735fe69d3254859689c1085f7c897fa6e9a9b828ad9d2c80ba7b6b2c4c67c942a6115262993147370!@asav-1.01.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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
On 09/24/2013 08:01 AM, jesper@krogh.cc wrote:
> This stuff is a 9.2 feature right? What was the original problem to be
> adressed?
Earlier, actually. 9.1? 9.0?
The problem addressed was that, for tables with a "progressive" value
like a sequence or a timestamp, the planner tended to estimate 1 row any
time the user queried the 10,000 most recent rows due to the stats being
out-of-date. This resulted in some colossally bad query plans for a
very common situation.
So there's no question that the current behavior is an improvement,
since it affects *only* users who have left an idle transaction open for
long periods of time, something you're not supposed to do anyway. Not
that we shouldn't fix it (and backport the fix), but we don't want to
regress to the prior planner behavior.
However, a solution is not readily obvious:
On 09/24/2013 03:35 AM, Tom Lane wrote:
> Kevin Grittner <kgrittn@ymail.com> writes:
>> > Are we talking about the probe for the end (or beginning) of an
>> > index? If so, should we even care about visibility of the row
>> > related to the most extreme index entry? Should we even go to the
>> > heap during the plan phase?
> Consider the case where some transaction inserted a wildly out-of-range
> value, then rolled back. If we don't check validity of the heap row,
> we'd be using that silly endpoint value for planning purposes ---
> indefinitely. That's not an improvement over the situation that the
> probe is meant to fix.
Agreed. And I'll also attest that the patch did fix a chronic bad
planner issue.
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.
Why do we need a procarraylock for this? Seems like the solution would
be not to take a lock at all; the information on transaction commit is
in the clog, after all.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
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: josh@agliodbs.com
Subject: Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
In-Reply-To: <5241CF2A.2070309@agliodbs.com>
* 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