Re: BUG #1753: Query Optimizer does not work well with libpg

From: Andrew - Supernews <andrew+nonews(at)supernews(dot)com>
To: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #1753: Query Optimizer does not work well with libpg
Date: 2005-07-06 00:03:01
Message-ID: slrndcm7tl.evl.andrew+nonews@trinity.supernews.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 2005-07-05, Oliver Jowett <oliver(at)opencloud(dot)com> wrote:
> Ernst Bachmann wrote:
>> The following bug has been logged online:
>>
>> Bug reference: 1753
>> Logged by: Ernst Bachmann
>> Email address: e(dot)bachmann(at)xebec(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Oliver Jowett 2005-07-06 00:25:28 Re: BUG #1753: Query Optimizer does not work well with libpg
Previous Message Oliver Jowett 2005-07-05 23:16:40 Re: BUG #1753: Query Optimizer does not work well with libpg