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

On 2005-07-06, Oliver Jowett <oliver@opencloud.com> wrote:
> Andrew - Supernews wrote:
>> 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.
>
> Sure, expression optimization is less aggressive, but is that on its own
> really going to produce a 100-fold difference in query execution?

Sure. Only for specific types of queries, of course.

> The main problem pre-8.0 (or with named statements) is that index
> selectivity estimates go out the window with a parameterized query, so a
> much more general (and slower) plan gets chosen. The 8.0
> unnamed-statement behaviour glues the actual parameter values into the
> selectivity estimates

correct so far...

> so in theory you should get the same plan for the unparameterized and
> parameterized-unnamed-statement cases.

But that doesn't follow, since selectivity estimation isn't the only
factor.

> This is why I'd like to see the actual query..

Yes, it would certainly help.

--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services