On Tue, Sep 9, 2014 at 12:01 PM, Andrew Gierth
<andrew@tao11.riddles.org.uk> wrote:
>>>>>> "Robert" == Robert Haas <robertmhaas@gmail.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