Re: EXISTS clauses not being optimized in the face of 'one time pass' optimizable expressions - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: EXISTS clauses not being optimized in the face of 'one time pass' optimizable expressions
Date
Msg-id CAHyXU0xqKnDYkpX53RiJyKtdau+3Rri+g3ARx8d5caRTt9+gVw@mail.gmail.com
Whole thread Raw
In response to Re: EXISTS clauses not being optimized in the face of 'one time pass' optimizable expressions  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Fri, Jul 1, 2016 at 11:45 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Merlin Moncure wrote:
>
>> It's pretty easy to craft a query where you're on the winning side,
>> but what's the worst case of doing two pass...is constant folding a
>> non trivial fraction of planning time?
>
> One thing that has been suggested is to re-examine the plan after
> planning is done, and if execution time is estimated to be large (FSVO),
> then run a second planning pass with more expensive optimizations
> enabled to try and find better plans.  The guiding principle would be to
> continue to very quickly find good enough plans for
> frequent/small/simple queries, but spend more planning effort on more
> complex ones where execution is likely to take much longer than planning
> time.
>
> So doing constant-folding twice would be enabled for the second planning
> pass.

I like this idea.  Maybe a GUC controlling the cost based cutoff (with
0 meaning, "assume the worst and plan the hard way first").

merlin



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: primary_conninfo missing from pg_stat_wal_receiver
Next
From: Tom Lane
Date:
Subject: Re: can we optimize STACK_DEPTH_SLOP