From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Atri Sharma <atri(dot)jiit(at)gmail(dot)com> |
Subject: | Re: WIP Patch for GROUPING SETS phase 1 |
Date: | 2014-09-09 16:11:30 |
Message-ID: | CA+TgmobZVd1qannT1NyXU25u5Q-jEeY_Wnh9rOjjUgNs_WTTBA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Sep 9, 2014 at 12:01 PM, Andrew Gierth
<andrew(at)tao11(dot)riddles(dot)org(dot)uk> wrote:
>>>>>> "Robert" == Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>
> Robert> Sure, showing the sort and aggregation steps is fine. But I
> Robert> don't see what advantage we get out of showing them like
> Robert> this:
>
> Robert> Aggregate
> Robert> -> Sort
> Robert> -> ChainAggregate
> Robert> -> Sort
> Robert> -> ChainAggregate
> Robert> -> Sort
>
> The advantage is that this is how the plan tree is actually
> structured.
I do understand that. I am questioning (as I believe Heikki was also)
whether it's structured correctly. Nobody is arguing for displaying
the plan tree in a way that doesn't mirror it's actual structure, or
at least I am not.
> The Sort node expects to have a child node to fetch rows from, and it
> expects all the usual plan tree mechanics (initialization, rescan,
> etc.) to work on that child node. There's no way for the parent to
> feed data to the child.
OK, good point. So we do need something that can feed data from one
part of the plan tree to another, like a CTE does. I still think it
would be worth trying to see if there's a reasonable way to structure
the plan tree so that it's flatter.
> Robert> From both a display perspective and an
> Robert> implementation-complexity perspective,
>
> ... says the person who has never tried implementing it.
This comment to me reads rather sharply, and I don't feel that the
tone of my email is such as to merit a rebuke.
> Honestly, ChainAggregate is _trivial_ compared to trying to make the
> GroupAggregate code deal with multiple inputs, or trying to make some
> new sort of plumbing node to feed input to those sorts. (You'd think
> that it should be possible to use the existing CTE mechanics to do it,
> but noooo... the existing code is actively and ferociously hostile to
> the idea of adding new CTEs from within the planner.)
That's unfortunate.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-09-09 16:21:22 | Re: WIP Patch for GROUPING SETS phase 1 |
Previous Message | Andrew Dunstan | 2014-09-09 16:03:22 | Re: [HACKERS] Problems with config.php and non default ports (postgresql - sugarcrm) |