Re: Prepared Statement Query Planning - Mailing list pgsql-jdbc

From Віталій Тимчишин
Subject Re: Prepared Statement Query Planning
Date
Msg-id 331e40660908291105m5166f9b8j58bfc2fe6584d57b@mail.gmail.com
Whole thread Raw
In response to Re: Prepared Statement Query Planning  (Brett Henderson <brett@bretth.com>)
Responses Re: Prepared Statement Query Planning  (Brett Henderson <brett@bretth.com>)
List pgsql-jdbc


2009/8/29 Brett Henderson <brett@bretth.com>
Oliver Jowett wrote:
Brett Henderson wrote:

It looks like you're using setFetchSize(). That forces use of a named statement regardless of prepareThreshold (we have to keep the statement and corresponding portal alive so we can do subsequent fetches, even if there are some other intervening queries, so we can't use the unnamed statement)
Yes, I'm currently using a fetch size of 10000.  I can't allow all results to be read at once because there can potentially be a huge number of results in the queries.  I've just tested it out, and sure enough leaving the fetch size at 0 prevents the use of named statements.

How about "create or replace temp view tmp_v as <query>" without setFetchSize and then "select * from tmp_v" with setFetchSize? Not sure still if DDL can use prepared query parameters.
Another options would be either to use protocolLevel=2 (writing from memory, may misspell parameter name) - this will force client-side parameter embedding or to embed your timestamps into query text by yourself and not to use PreparedStatement at all. Fortunatelly this are not strings - so no quoting needed.

Best regards, Vitalii Tymchyshyn

pgsql-jdbc by date:

Previous
From: Tom Lane
Date:
Subject: Re: Prepared Statement Query Planning
Next
From: Brett Henderson
Date:
Subject: Re: Prepared Statement Query Planning