Re: WIP Patch for GROUPING SETS phase 1 - Mailing list pgsql-hackers

From Robert Haas
Subject Re: WIP Patch for GROUPING SETS phase 1
Date
Msg-id CA+TgmobZVd1qannT1NyXU25u5Q-jEeY_Wnh9rOjjUgNs_WTTBA@mail.gmail.com
Whole thread Raw
In response to Re: WIP Patch for GROUPING SETS phase 1  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: WIP Patch for GROUPING SETS phase 1
List 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 by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Problems with config.php and non default ports (postgresql - sugarcrm)
Next
From: Tom Lane
Date:
Subject: Re: WIP Patch for GROUPING SETS phase 1