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

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: EXISTS clauses not being optimized in the face of 'one time pass' optimizable expressions
Дата
Msg-id CAHyXU0xVjiQR1pdbA1Cutmu3OjLHML4_CZiAdg3astogRKxWLw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: EXISTS clauses not being optimized in the face of 'one time pass' optimizable expressions  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: EXISTS clauses not being optimized in the face of 'one time pass' optimizable expressions  (Robert Haas <robertmhaas@gmail.com>)
Re: EXISTS clauses not being optimized in the face of 'one time pass' optimizable expressions  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
On Fri, Jul 1, 2016 at 10:27 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Jul 1, 2016 at 10:20 AM, Merlin Moncure <mmoncure@gmail.com> wrote:
>> Yeah.  Also, even if you could parse out those cases, it's major
>> optimization fence.  Consider if you have an ORDER BY clause here:
>>
>> SELECT FROM foo WHERE a OR b ORDER BY c;
>>
>> ... by pushing inside a union, you're going to be in trouble in real
>> world cases.  That's just a mess and it would add a lot of runtime
>> analysis of the alternative paths.  It's hard for me to believe
>> rewriting is easier and simpler than rewriting 'false OR x' to 'x'.  I
>> also thing that constant folding strategies are going to render much
>> more sensible output to EXPLAIN.
>
> I don't think that it's easier and simpler and didn't intend to say
> otherwise.  I do think that I've run across LOTS of queries over the
> years where rewriting OR using UNION ALL was a lot faster, and I think
> that case is more likely to occur in practice than FALSE OR WHATEVER.
> But, I'm just throwing out opinions to see what sticks here; I'm not
> deeply invested in this.

Sure (I didn't put you on that position, just thinking out loud).  The
problem with UNION ALL is that it's only safe to do so when you know
for sure the both sides of the partition are non-overlapping.  The
author of the query often knows this going in but for the planner it's
not so simple to figure out in many cases.  If there's a subset of
cases.   UNION sans ALL is probably a dead end on performance grounds.

This hinges on Tom's earlier statements, "Much of
the value of doing constant-folding would disappear if we ran it before
subquery pullup + join simplification, because in non-stupidly-written
queries those are what expose the expression simplification opportunities."

and, especially, "We could run it twice but that seems certain to be a
dead loser most of
the time."

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?

merlin



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Documentation fixes for pg_visibility
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: EXISTS clauses not being optimized in the face of 'one time pass' optimizable expressions