Message-ID: <e8795f5e292a0bd1a4d8ebbcb54e4a98.squirrel@shrek.krogh.cc>
In-Reply-To: <5815.1380018947@sss.pgh.pa.us>
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>
Date: Tue, 24 Sep 2013 17:01:14 +0200 (CEST)
Subject: Re: Planner performance extremely affected by an hanging
 transaction (20-30 times)?
From: jesper@krogh.cc
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Kevin Grittner" <kgrittn@ymail.com>, "Jeff Janes" <jeff.janes@gmail.com>,
 =?iso-8859-1?Q?Bart=C5=82omiej_Roma=C5=84ski?= <br@sentia.pl>,
 "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
User-Agent: SquirrelMail/1.4.15
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

> 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.

Apparently it is waiting for locks, cant the check be make in a
"non-blocking" way, so if it ends up waiting for a lock then it just
assumes non-visible and moves onto the next non-blocking?

This stuff is a 9.2 feature right? What was the original problem to be
adressed?

-- 
Jesper


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance