Re: WIP Patch for GROUPING SETS phase 1

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