Re: How embarrassing: optimization of a one-shot query doesn't work
От | Dave Cramer |
---|---|
Тема | Re: How embarrassing: optimization of a one-shot query doesn't work |
Дата | |
Msg-id | CE33CCC7-61C3-4D34-BED9-D8D884FC14AA@fastcrypt.com обсуждение исходный текст |
Ответ на | How embarrassing: optimization of a one-shot query doesn't work (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: How embarrassing: optimization of a one-shot query doesn't work
|
Список | pgsql-jdbc |
Tom, I believe this is pretty much a show stopper for anyone using jdbc to upgrade to 8.3.x. Any word on 8.3.2 ? Dave On 31-Mar-08, at 7:26 PM, Tom Lane wrote: > 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%'. > > Some investigation showed that the planner is using the passed values > for estimation purposes, but not for any purposes where the value > *must* > be correct (not only this LIKE-optimization, but constraint exclusion, > for instance). The reason is that the parameter values are made > available to estimate_expression_value but not to > eval_const_expressions. > This is a thinko in a cleanup patch I made early in 8.3 development: > http://archives.postgresql.org/pgsql-committers/2007-02/msg00352.php > I said to myself "eval_const_expressions doesn't need any context, > because a constant expression's value must be independent of context, > so I can avoid changing its API". Silly me. > > 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? > > regards, tom lane > > -- > Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-jdbc
В списке pgsql-jdbc по дате отправления: