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

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?

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 so in theory you should get the same plan for the
unparameterized and parameterized-unnamed-statement cases.

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

-O