>>>>> "Robert" == Robert Haas <robertmhaas@gmail.com> writes:
Robert> Sure, showing the sort and aggregation steps is fine. But IRobert> don't see what advantage we get out of
showingthem likeRobert> this:
Robert> AggregateRobert> -> SortRobert> -> ChainAggregateRobert> -> SortRobert> ->
ChainAggregateRobert> -> Sort
The advantage is that this is how the plan tree is actually
structured.
Robert> When we could show them like this:
Robert> AggregateRobert> -> SortRobert> -> SortRobert> -> 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 anRobert> 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)