On Wed, Dec 31, 2014 at 05:33:43PM +0000, Andrew Gierth wrote:
> >>>>> "Noah" == Noah Misch <noah@leadboat.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.
The opaque-blob criticism is valid. As for not gaining much, well, the gain I
sought was to break this stalemate. You and Tom have expressed willingness to
accept the read I/O multiplier of the CTE approach. You and I are willing to
swallow an architecture disruption, namely a tuplestore acting as a side
channel between executor nodes. Given your NACK, I agree that it fails to
move us toward consensus and therefore does not gain much. Alas.
> 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.
That's a fair criticism, too. Ingesting nodeSort.c into nodeAgg.c wouldn't be
too bad, because nodeSort.c is a thin wrapper around tuplesort.c. Ingesting
nodeHash.c is not so tidy; that could entail extracting a module similar in
level to tuplesort.c, to be consumed by both executor nodes. This does raise
the good point that the GROUPING SETS _design_ ought to consider group and
hash aggregation together. Designing one in isolation carries too high of a
risk of painting the other into a corner.
Thanks,
nm