Re: Final Patch for GROUPING SETS

On 12/31/14, 3:05 PM, Noah Misch wrote:
> 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.

I haven't read the full discussion in depth, but is what we'd want here is the ability to feed tuples to more than one
nodesimultaneously? That would allow things like
 

GroupAggregate
--> Sort(a) \
------------+--> Sort(a,b) -\
--> Hash(b) ----------------+                            \--> SeqScan

That would allow the planner to trade off things like total memory consumption vs IO.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com