Re: Prepared Statement Query Planning
От | Віталій Тимчишин |
---|---|
Тема | Re: Prepared Statement Query Planning |
Дата | |
Msg-id | 331e40660908291105m5166f9b8j58bfc2fe6584d57b@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Prepared Statement Query Planning (Brett Henderson <brett@bretth.com>) |
Ответы |
Re: Prepared Statement Query Planning
|
Список | pgsql-jdbc |
2009/8/29 Brett Henderson <brett@bretth.com>
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.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)
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 по дате отправления: