Re: [HACKERS] How embarrassing: optimization of a one-shot query doesn't work

On 1-Apr-08, at 6:25 AM, Michael Paesold wrote:

>
> 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.
>
Was the driver ever changed to take advantage of the above strategy?

Dave
> Best Regards
> Michael Paesold
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc