Re: Final Patch for GROUPING SETS

>>>>> "Noah" == Noah Misch <noah(at)leadboat(dot)com> writes:

Noah> Suppose one node orchestrated all sorting and aggregation.

Well, that has the downside of making it into an opaque blob, without
actually gaining much.

Noah> Call it a MultiGroupAggregate for now. It wouldn't harness
Noah> Sort nodes, because it performs aggregation between
Noah> tuplesort_puttupleslot() calls. Instead, it would directly
Noah> manage two Tuplesortstate, CUR and NEXT. The node would have
Noah> an initial phase similar to ExecSort(), in which it drains the
Noah> outer node to populate the first CUR. After that, it looks
Noah> more like agg_retrieve_direct(),

agg_retrieve_direct is already complex enough, and this would be
substantially more so, as compared to agg_retrieve_chained which is
substantially simpler.

A more serious objection is that this forecloses (or at least makes
much more complex) the future possibility of doing some grouping sets
by sorting and others by hashing. The chained approach specifically
allows for the future possibility of using a HashAggregate as the
chain head, so that for example cube(a,b) can be implemented as a
sorted agg for (a,b) and (a) and a hashed agg for (b) and (), allowing
it to be done with one sort even if the result size for (a,b) is too
big to hash.

Noah> Tom, Andrew, does that look satisfactory?

Not to me.

--
Andrew (irc:RhodiumToad)