On 10/18/06, Bucky Jordan <bjordan@xxxxxxxxxx> wrote:
> On 10/17/06, Rohit_Behl <Rohit_Behl@xxxxxxxxxxx> wrote: > > Select events.event_id, ctrl.real_name, events.tsds, events.value, > events.lds, events.correction, ctrl.type, ctrl.freq from table events, > iso_midw_control ctrl where events.obj_id = ctrl.obj_id and > events.event_id > ?::bigint order by events.event_id limit ? >
After a quick search on the JDBC list, it looks like there's some recent discussion on the subject of how to give the planner better insight for prepared statements (the subject is "Blind Message" if you're looking...). So, I'm off to go read there and perhaps join the jdbc mailing list too.
this is not really a jdbc issue, just a practical problem with prepared statements...except for the mechanism if any the jdbc driver allows you to choose if a statement is prepared.
But, a more general postgres question. I assume if I want to turn prepared statements off altogether (say I'm using a jdbc abstraction
you turn off prepared statements by not invoking sql prepare or PQprepare. (or, if jdbc implements its own protocol client, it's version of PQprepare).
layer that likes parameterized statements, and there's other benefits to parameterizing other than just saving on db parse/plan) can I set max_prepared_transactions to 0? Is there any other option outside of
this setting is for 2pc and is not relevent to the discussion :) even if it were, im not so sure about a setting designed to enforce a partcular method of querying. yes, you are correct this is not exactly the use case for hints being discussed in -hackers. however, imho, this is much more important and relevant so long as prepared statements continue to work the way they do. merlin
