Re: WIP: Upper planner pathification - Mailing list pgsql-hackers

From Greg Stark
Subject Re: WIP: Upper planner pathification
Date
Msg-id CAM-w4HNhj0UwNuZ_aoJowWBzMaWkJY_qUZK-RxWGw5NWShe-Jw@mail.gmail.com
Whole thread Raw
In response to Re: WIP: Upper planner pathification  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: WIP: Upper planner pathification  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Aleksander Alekseev
Date:
Subject: Re: Patch: fix lock contention for HASHHDR.mutex
Next
From: Pavel Stehule
Date:
Subject: Re: Sort returns more rows than seq scan?