>>>>> "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. 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) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
