Am 01.04.2008 um 01:26 schrieb Tom Lane:
While testing the changes I was making to Pavel's EXECUTE USING patch
to ensure that parameter values were being provided to the planner,
it became painfully obvious that the planner wasn't actually *doing*
anything with them. For example
execute 'select count(*) from foo where x like $1' into c using $1;
wouldn't generate an indexscan when $1 was of the form 'prefix%'.
...
The implication of this is that 8.3 is significantly worse than 8.2
in optimizing unnamed statements in the extended-Query protocol;
a feature that JDBC, at least, relies on.
The fix is simple: add PlannerInfo to eval_const_expressions's
parameter list, as was done for estimate_expression_value. I am
slightly hesitant to do this in a stable branch, since it would break
any third-party code that might be calling that function. I doubt
there
is currently any production-grade code doing so, but if anyone out
there
is actively using those planner hooks we put into 8.3, it's
conceivable
this would affect them.
Still, the performance regression here is bad enough that I think
there
is little choice. Comments/objections?
Yeah, please fix this performance regression in the 8.3 branch. This
would affect most of the JDBC applications out there, I think.
Best Regards
Michael Paesold
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
