I'm already at it
It is a Java app, using jdbc, but through a proprietary persistence framework.
I'm just busy evaluating the effects on the app of prohibiting prepared statements via jdbc.
If this is not worthwhile, I'm bound to some expensive reorganizations, sigh.
Nevertheless,
thanks for your help
in reminding me about obvious use of prepared statements.
Rainer
PS:
I've just read the thread on "Avoiding bad prepared-statement plans".
Very interesting. Will track this...
Am 01.03.2010 19:15, wrote Tom Lane:
> Rainer Pruy <Rainer.Pruy@Acrys.COM> writes:
>> The prepared statement gives:
>> ...
>> And that is quite a bad plan given the current distribution of values.
>
> Yeah. The planner really needs to know the actual parameter values in
> order to pick the best plan for this case.
>
> One thing that you might be able to do to avoid giving up on prepared
> statements entirely is to use an "unnamed" rather than named prepared
> statement here. That will lead to the query plan being prepared only
> when the parameter values are made available, rather than in advance.
> It'd depend on what client library you're using whether this is a simple
> change or not.
>
> regards, tom lane