On Wed, 21 Apr 2010, Robert Haas wrote:
On Tue, Apr 20, 2010 at 5:05 PM, Kris Jurka <books@xxxxxxxxxx> wrote:
b) Using the parameter values for statistics, but not making any stronger
guarantees about them. So the parameters will be used for evaluating the
selectivity, but not to perform other optimizations like contraint_exclusion
or transforming a LIKE operation to a range query. This is the default plan
type the JDBC driver uses.
Hmm. I didn't think this was possible. How are you doing this?
This is only possible at the protocol level, it's not available using SQL
commands only. You do this by creating an unnamed instead of a named
statement:
http://www.postgresql.org/docs/8.4/static/protocol-flow.html#PROTOCOL-FLOW-EXT-QUERY
Query planning for named prepared-statement objects occurs when
the Parse message is processed. If a query will be repeatedly
executed with different parameters, it might be beneficial to send
a single Parse message containing a parameterized query, followed
by multiple Bind and Execute messages. This will avoid replanning
the query on each execution.
The unnamed prepared statement is likewise planned during Parse
processing if the Parse message defines no parameters. But if
there are parameters, query planning occurs during Bind processing
instead. This allows the planner to make use of the actual values
of the parameters provided in the Bind message when planning the
query.
Kris Jurka
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
