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>
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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Prepared Statement Query Planning
Следующее
От: Brett Henderson
Дата:
Сообщение: Re: Prepared Statement Query Planning