From: Tom Lane <tgl@sss.pgh.pa.us>
To: Kevin Grittner <kgrittn@ymail.com>
Cc: Jeff Janes <jeff.janes@gmail.com>
Cc: Bartłomiej Romański <br@sentia.pl>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
Date: Tue, 24 Sep 2013 12:35:47 +0200
Message-ID: <5815.1380018947@sss.pgh.pa.us> (raw)
In-Reply-To: <1379944816.30390.YahooMailNeo@web162903.mail.bf1.yahoo.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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
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.
regards, tom lane
--
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: tgl@sss.pgh.pa.us, kgrittn@ymail.com, jeff.janes@gmail.com, br@sentia.pl
Subject: Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
In-Reply-To: <5815.1380018947@sss.pgh.pa.us>
* 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