DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=ymail.com;
 h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
 b=UUEBhjqnO6dcJNvjP0sVv1bmbpa5WEpbaJBGFKRS1A7nza5Gjw9sLRyg3bMhW0QEOurGvVitJeoN1RFgid+BvmSq2gz6ghFKACX0sM62NJ2TJiS52Ye6z423NXPhwPSHNnY2s5dS7IyNLFQ1bSkjnSDvTHpjtA9MhOUuRpgD8oc=;
References: 
 <WM!f3d412a8ff9fb2a52f4cfd0f48c225b6122ba5bf1e1523173b5dbc63db143b9cab09ac3f5518a12a19d2507538472d98!@asav-1.01.com>
 <51A79512.4020200@agliodbs.com>
 <WM!c84cb8479a8b2ec21d1061c951095da00bc52608e9822124f1438b9de432ec7ebedaf25085801b67d581eed6d368c344!@asav-2.01.com>
 <51FAA1B8.6040809@agliodbs.com>
 <CAMkU=1wn3npjTjEkC8rYMgmoKXYoAgfxosT_Q3v_=wTfriPKdA@mail.gmail.com>
 <522E69F1.8070203@dunslane.net> <20130910122036.GF1024477@alap2.anarazel.de>
 <522F146D.2070908@dunslane.net>
 <WM!21a18aa9cbf2098b3ceb8d93a0769806466db819c328e3d732b1667507e087969764ace79b57bc4d6e54a0bce329a6fa!@asav-3.01.com>
 <5230B801.90507@agliodbs.com> <20130911211253.GF1138556@alap2.anarazel.de>
 <WM!c3606120c0bb347c33db79557781a3bddaeb55ccb41e40a3859a4dc0d258d194010ad0001617c701ce31e795a28cb6ca!@asav-2.01.com>
 <523120E9.6020300@agliodbs.com> <24236.1383940000@sss.pgh.pa.us>
Message-ID: <1384014645.82057.YahooMailNeo@web162903.mail.bf1.yahoo.com>
Date: Sat, 9 Nov 2013 08:30:45 -0800 (PST)
From: Kevin Grittner <kgrittn@ymail.com>
Reply-To: Kevin Grittner <kgrittn@ymail.com>
Subject: Re: Performance bug in prepared statement binding in 9.2?
To: Tom Lane <tgl@sss.pgh.pa.us>, Josh Berkus <josh@agliodbs.com>
Cc: Andres Freund <andres@2ndquadrant.com>,
 Andrew Dunstan <andrew@dunslane.net>, Jeff Janes <jeff.janes@gmail.com>,
 Amit Kapila <amit.kapila@huawei.com>,
 "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
In-Reply-To: <24236.1383940000@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Tom Lane <tgl@sss.pgh.pa.us> wrote:

> I wonder if we could ameliorate this problem by making
> get_actual_variable_range() use SnapshotDirty

> In that thread I claimed that a current MVCC snapshot was the
> most appropriate thing, which it probably is;

If it reads from the end of the index, won't it actually be reading
starting with the value we will obtain using SnapshotDirty, and
since the transaction is not yet committed, won't we be making the
trip to the heap for each index tuple we read from that point?=A0 Why
doesn't that make SnapshotDirty more appropriate for purposes of
cost estimation?

> but the argument for it isn't so strong that I think we should be
> willing to spend unbounded effort to get that version of the
> column min/max rather than some other approximation.

Since the whole point is to try to get the fastest runtime which
produces correct results, I agree even if the other value is in
some way more "correct".

> The best objection to it that I can see is Robert's security
> concern about leakage of uncommitted values --- but I don't think
> that holds a huge amount of water either.
It doesn't look like Robert did either, if you read the whole
message.=A0 In fact, he also questioned why index tuples which would
need to be read if we process from that end of the index don't
matter for purposes of cost estimation.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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