On Wed, Dec 31, 2014 at 02:45:29PM +0530, Atri Sharma wrote:
> > Suppose one node orchestrated all sorting and aggregation. Call it a
> > MultiGroupAggregate for now. It wouldn't harness Sort nodes, because it
> > performs aggregation between tuplesort_puttupleslot() calls. Instead, it
> > would directly manage two Tuplesortstate, CUR and NEXT. The node would
> > have
> > an initial phase similar to ExecSort(), in which it drains the outer node
> > to
> > populate the first CUR. After that, it looks more like
> > agg_retrieve_direct(),
> > except that CUR is the input source, and each tuple drawn is also put into
> > NEXT. When done with one CUR, swap CUR with NEXT and reinitialize NEXT.
> > This
> > design does not add I/O consumption or require a nonstandard communication
> > channel between executor nodes. Tom, Andrew, does that look satisfactory?
> >
> >
> So you are essentially proposing merging ChainAggregate and its
> corresponding Sort node?
>
> So the structure would be something like:
>
> GroupAggregate
> --> MultiGroupAgg (a,b)
> ----> MultiGroupAgg (c,d) ...
No.
> If you are proposing
> replacing GroupAggregate node + entire ChainAggregate + Sort nodes stack
> with a single MultiGroupAggregate node, I am not able to understand how it
> will handle all the multiple sort orders.
Yes, I was proposing that. My paragraph that you quoted above was the attempt
to explain how the node would manage multiple sort orders. If you have
specific questions about it, feel free to ask.
