Re: Performance bug in prepared statement binding in 9.2?

From: Kevin Grittner <kgrittn(at)ymail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Performance bug in prepared statement binding in 9.2?
Date: 2013-11-09 16:30:45
Message-ID: 1384014645.82057.YahooMailNeo@web162903.mail.bf1.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message monalee_dba 2013-11-10 07:32:14 BitMap Heap Scan & BitMap Index Scan
Previous Message Tom Lane 2013-11-08 19:46:40 Re: Performance bug in prepared statement binding in 9.2?