Re: WIP Patch for GROUPING SETS phase 1

>>>>> "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.

Robert> When we could show them like this:

Robert> Aggregate
Robert> -> Sort
Robert> -> Sort
Robert> -> Sort

And we can't structure the plan tree like this, because then it
wouldn't be a _tree_ any more.

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.

Robert> From both a display perspective and an
Robert> implementation-complexity perspective,

... says the person who has never tried implementing it.

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.)

--
Andrew (irc:RhodiumToad)