On Wed, Dec 31, 2014 at 05:33:43PM +0000, Andrew Gierth wrote: > >>>>> "Noah" == Noah Misch <n...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
