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.
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 |