On 2005-07-06, Oliver Jowett <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
