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

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> 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?

I agree that we should update stable to fix this performance regression,
given the gravity of it. I also feel that we need to do so ASAP, to
minimize the risk of people being affected by it. The longer we wait on
it the more likely someone will write something which is affected.

The constraint-exclusion not being used will be a huge impact and
problem for people moving partitioned-data with dynamic pl/pgsql
generation functions to 8.3.

Robert, I'm suprised you weren't affected, or have you just not noticed
yet due to your fancy new-to-you hardware? ;)

Stephen