On Tue, Mar 1, 2016 at 2:30 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
