Re: How embarrassing: optimization of a one-shot query doesn't work - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: How embarrassing: optimization of a one-shot query doesn't work
Date
Msg-id 20080401004643.GL4999@tamriel.snowman.net
Whole thread Raw
In response to How embarrassing: optimization of a one-shot query doesn't work  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: How embarrassing: optimization of a one-shot query doesn't work  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
* Tom Lane (tgl@sss.pgh.pa.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

Attachment

pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: Guessing future postgresql features
Next
From: "Jonah H. Harris"
Date:
Subject: Re: Guessing future postgresql features