Re: EXISTS clauses not being optimized in the face of 'one time pass' optimizable expressions

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: EXISTS clauses not being optimized in the face of 'one time pass' optimizable expressions
Date: 2016-07-06 12:46:00
Message-ID: CAHyXU0xqKnDYkpX53RiJyKtdau+3Rri+g3ARx8d5caRTt9+gVw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 1, 2016 at 11:45 AM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-07-06 13:34:49 Re: can we optimize STACK_DEPTH_SLOP
Previous Message Michael Paquier 2016-07-06 11:26:41 Re: primary_conninfo missing from pg_stat_wal_receiver