Re: SOLVED ... Re: Getting rid of a cursor from JDBC .... Re: [PERFORM] Re: HELP: How to tame the 8.3.x JDBC driver with a biq guery result set

On Wed, 21 Apr 2010, Robert Haas wrote:

> On Tue, Apr 20, 2010 at 5:05 PM, Kris Jurka <books@ejurka.com> 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