Re: WIP: Upper planner pathification

From: Greg Stark <stark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Teodor Sigaev <teodor(at)sigaev(dot)ru>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP: Upper planner pathification
Date: 2016-03-01 14:45:24
Message-ID: CAM-w4HNhj0UwNuZ_aoJowWBzMaWkJY_qUZK-RxWGw5NWShe-Jw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 1, 2016 at 2:30 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2016-03-01 14:52:26 Re: Sort returns more rows than seq scan?
Previous Message Tom Lane 2016-03-01 14:45:12 Re: Sort returns more rows than seq scan?