From: Tom Lane <tgl@sss.pgh.pa.us>
To: Kevin Grittner <kgrittn@ymail.com>
cc: Jeff Janes <jeff.janes@gmail.com>,
 =?utf-8?B?QmFydMWCb21pZWogUm9tYcWEc2tp?= <br@sentia.pl>,
 "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: Planner performance extremely affected by an hanging transaction
 (20-30 times)?
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>
Comments: In-reply-to Kevin Grittner <kgrittn@ymail.com>
 message dated "Mon, 23 Sep 2013 07:00:16 -0700"
Date: Tue, 24 Sep 2013 12:35:47 +0200
Message-ID: <5815.1380018947@sss.pgh.pa.us>
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.

			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