>>>>> "Robert" == Robert Haas <robertmh...@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. 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) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
