pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Kevin Grittner <kgrittn@ymail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
To: Josh Berkus <josh@agliodbs.com>
Cc: Andres Freund <andres@2ndquadrant.com>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: Jeff Janes <jeff.janes@gmail.com>
Cc: Amit Kapila <amit.kapila@huawei.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Performance bug in prepared statement binding in 9.2?
Date: Sat, 9 Nov 2013 08:30:45 -0800 (PST)
Message-ID: <1384014645.82057.YahooMailNeo@web162903.mail.bf1.yahoo.com> (raw)
In-Reply-To: <24236.1383940000@sss.pgh.pa.us>
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>
List-Unsubscribe:  <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>

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


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



view thread (43+ messages)  latest in thread

Message-ID: <1384014645.82057.YahooMailNeo@web162903.mail.bf1.yahoo.com>
Permalink:  ../1384014645.82057.YahooMailNeo@web162903.mail.bf1.yahoo.com/
Also on:    postgresql.org/message-id/1384014645.82057.YahooMailNeo@web162903.mail.bf1.yahoo.com

 · 

reply
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: kgrittn@ymail.com, tgl@sss.pgh.pa.us, josh@agliodbs.com, andres@2ndquadrant.com, andrew@dunslane.net, jeff.janes@gmail.com, amit.kapila@huawei.com
  Subject: Re: Performance bug in prepared statement binding in 9.2?
  In-Reply-To: <1384014645.82057.YahooMailNeo@web162903.mail.bf1.yahoo.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