From: | Віталій Тимчишин <tivv00(at)gmail(dot)com> |
---|---|
To: | Brett Henderson <brett(at)bretth(dot)com> |
Cc: | Oliver Jowett <oliver(at)opencloud(dot)com>, pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Prepared Statement Query Planning |
Date: | 2009-08-29 18:05:27 |
Message-ID: | 331e40660908291105m5166f9b8j58bfc2fe6584d57b@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
2009/8/29 Brett Henderson <brett(at)bretth(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Brett Henderson | 2009-08-30 06:16:45 | Re: Prepared Statement Query Planning |
Previous Message | Tom Lane | 2009-08-29 14:52:45 | Re: Prepared Statement Query Planning |