On 2005-07-05, Oliver Jowett <[EMAIL PROTECTED]> wrote: > Ernst Bachmann wrote: >> The following bug has been logged online: >> >> Bug reference: 1753 >> Logged by: Ernst Bachmann >> Email address: [EMAIL PROTECTED] >> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
