Re: Interesting results using new prepared statements - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Interesting results using new prepared statements
Date
Msg-id 9528.1031861555@sss.pgh.pa.us
Whole thread Raw
In response to Interesting results using new prepared statements  (Barry Lind <barry@xythos.com>)
Responses Re: Interesting results using new prepared statements  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Barry Lind <barry@xythos.com> writes:
> ... I don't understand
> why the timings for prepared statements would be less than for a regular
> statement, and especially why using bind variables would be better than
> without.  I am concerned that prepared statements may be choosing a
> different execution plan than non-prepared statements.

That's entirely likely if you are using bind variables in the prepared
statements, since the planner will not have access to the same constant
values that it does in a plain SQL statement --- for example, "WHERE foo
= $1" looks a lot different from "WHERE foo = 42" to the planner.

In most cases I'd expect the planner to generate worse plans when given
less info :-( ... but in your particular case it seems to be guessing
slightly wrong.

> But I am not
> sure how to find out what the execution plan is for a prepared
> statement, since EXPLAIN doesn't work for a prepared statement (i.e.
> EXPLAIN EXECUTE <preparedStatementName>, doesn't work).

Hmmm --- I can see the usefulness of that, but it looks like a new
feature and hence verboten during beta.  Maybe a TODO for 7.4?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Justin Clift
Date:
Subject: Looking for more "big name" places that use PostgreSQL
Next
From: Tom Lane
Date:
Subject: Re: beta1 packaged