On 2005-07-05, Oliver Jowett <oliver@opencloud.com> wrote:
> Ernst Bachmann wrote:
>> The following bug has been logged online:
>>
>> Bug reference: 1753
>> Logged by: Ernst Bachmann
>> Email address: e.bachmann@xebec.de
>> PostgreSQL version: 8.0.3
>> Operating system: Linux
>> Description: Query Optimizer does not work well with libpg /
>> PQexecParams
>> Details:
>>
>> It looks like the query optimizer isn't taking the value of parameters sent
>> with PQexecParams into account, thus generating (in my case, very) unoptimal
>> plans
>
> If PQexecParams uses the unnamed statement (it appears to), this
> shouldn't happen -- planning of the unnamed statement is delayed until
> the first set of parameter values is bound. This behaviour started in 8.0.
The problem is that even with the unnamed statement and deferred planning,
the planner still has to treat the parameters as variables, not constants,
since nothing in the protocol stops you from running multiple portals from
the unnamed statement. This can make a significant difference, especially
where function calls are involved and major optimizations can be made on
constant values as a result of inlining.
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services
