Re: WIP: Upper planner pathification

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: WIP: Upper planner pathification
Дата
Msg-id CAM-w4HNhj0UwNuZ_aoJowWBzMaWkJY_qUZK-RxWGw5NWShe-Jw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: WIP: Upper planner pathification  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: WIP: Upper planner pathification  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, Mar 1, 2016 at 2:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> There are a couple of
> regression test cases that change plans for the better, but it's sort of
> accidental.  Those cases look like
>
>   select d.* from d left join (select * from b group by b.id, b.c_id) s
>     on d.a = s.id;
>
> and what happens in HEAD is that the subquery chooses a hashagg plan
> and then the upper query decides a mergejoin would be a good idea ...
> so it has to sort the output of the hashagg.  With the patch, what
> comes back from the subquery is a Path for the hashagg and a Path
> for doing the GROUP BY with Sort/Uniq.  The second path is more expensive,
> but it survives the add_path tournament because it can produce sorted
> output.  Then the outer level discovers that it can use that to do its
> mergejoin without a separate sort step, and that way is cheaper overall.

This doesn't sound accidental at all. It sounds like a perfect example
of exactly the benefits of this approach.

I read through the patch just to get an idea what's changing. But
obviously that's not going to actually turn up anything surprising.

(Actually the first hunk in the patch kind of surprised me. Do we dump
node trees with -> notation currently? I thought they normally all
looked like sexpressions.)



-- 
greg



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

Предыдущее
От: Aleksander Alekseev
Дата:
Сообщение: Re: Patch: fix lock contention for HASHHDR.mutex
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: Sort returns more rows than seq scan?