Re: Final Patch for GROUPING SETS - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: Final Patch for GROUPING SETS
Date
Msg-id 87d26zd9k8.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: Final Patch for GROUPING SETS  (Noah Misch <noah@leadboat.com>)
Responses Re: Final Patch for GROUPING SETS
List pgsql-hackers
>>>>> "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.
Noah> Call it a MultiGroupAggregate for now.  It wouldn't harnessNoah> Sort nodes, because it performs aggregation
betweenNoah>tuplesort_puttupleslot() calls.  Instead, it would directlyNoah> manage two Tuplesortstate, CUR and NEXT.
Thenode would haveNoah> an initial phase similar to ExecSort(), in which it drains theNoah> outer node to populate the
firstCUR.  After that, it looksNoah> 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)



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Using 128-bit integers for sum, avg and statistics aggregates
Next
From: Tomas Vondra
Date:
Subject: Re: Initdb-cs_CZ.WIN-1250 buildfarm failures