Re: WIP Patch for GROUPING SETS phase 1
От | Robert Haas |
---|---|
Тема | Re: WIP Patch for GROUPING SETS phase 1 |
Дата | |
Msg-id | CA+TgmobZVd1qannT1NyXU25u5Q-jEeY_Wnh9rOjjUgNs_WTTBA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WIP Patch for GROUPING SETS phase 1 (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
Ответы |
Re: WIP Patch for GROUPING SETS phase 1
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: