Re: Adaptive query execution

From: Claudio Freire <klaussfreire(at)gmail(dot)com>
To: Tim Kane <tim(dot)kane(at)gmail(dot)com>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Adaptive query execution
Date: 2014-05-13 20:13:42
Message-ID: CAGTBQpY9+iYnkOeSYXDJ3V_VJnZczsXpgSbzF5BEjv9SpDvcnA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, May 13, 2014 at 5:08 PM, Tim Kane <tim(dot)kane(at)gmail(dot)com> wrote:
> Hi all,
>
> So I was thinking about the following, after experimenting with constraint
> exclusion.
>
> I thought I would see what happens when I do this:
>
> SELECT * FROM ONLY table_a UNION SELECT * FROM table_b;
>
>
> I noticed that despite table_a still having no data in it, the planner has
> already decided that it needs to insert a chain of ‘append->sort->unique’
> nodes into the plan.
>
> That’s fairly reasonable.
> While I understand that we can’t readily know about wether a given node will
> return anything or not - would it be possible to have the execution engine
> branch off in the event that a given node returns nothing at all?
>
> I guess there are probably a lot of considerations, and I suspect it would
> considerably increase planning time, though maybe it also presents an
> opportunity for some interesting approaches to adaptive query execution.

What's the point, in the context of this example?

The sort-unique still has to be performed even if you didn't have data
in one side, since the other could still have duplicates.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2014-05-13 20:24:39 Re: Constraint exclusion won't exclude parent table
Previous Message Tim Kane 2014-05-13 20:08:09 Adaptive query execution