pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: 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: Fri, 08 Nov 2013 14:46:40 -0500
Message-ID: <24236.1383940000@sss.pgh.pa.us> (raw)
In-Reply-To: <523120E9.6020300@agliodbs.com>
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>
List-Unsubscribe:  <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>

Josh Berkus <josh@agliodbs.com> writes:
>> The explanation is in
>> http://archives.postgresql.org/message-id/20130910132133.GJ1024477%40alap2.anarazel.de
>> 
>> The referenced commit introduced a planner feature. Funnily you seem to
>> have been the trigger for it's introduction ;)

> Oh, crap, the "off the end of the index" optimization?

> It's the story of our lives: we can't optimize anything without
> deoptimizing something else.  Dammit.

I wonder if we could ameliorate this problem by making
get_actual_variable_range() use SnapshotDirty rather than either
SnapshotNow (as it does in released versions) or the active snapshot (as
it does in HEAD).  We discussed that idea in the SnapshotNow removal
thread, see eg
http://www.postgresql.org/message-id/CA+TgmoZ_q2KMkxZAoRxRHB7k1tOmjVjQgYt2JuA7=U7QZoLxNw@mail.gmail....
In that thread I claimed that a current MVCC snapshot was the most
appropriate thing, which it probably is; 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.
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.  We already try to limit the visibility of the
regular elements of the histogram, why are these not-yet-committed values
significantly more of an issue?

			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



view thread (43+ messages)  latest in thread

Message-ID: <24236.1383940000@sss.pgh.pa.us>
Permalink:  ../24236.1383940000@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/24236.1383940000@sss.pgh.pa.us

 · 

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: 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: <24236.1383940000@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