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
