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

From Noah Misch
Subject Re: Final Patch for GROUPING SETS
Date
Msg-id 20150103175320.GB2241798@tornado.leadboat.com
Whole thread Raw
In response to Re: Final Patch for GROUPING SETS  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: Final Patch for GROUPING SETS
List pgsql-hackers
On Fri, Jan 02, 2015 at 03:55:23PM -0600, Jim Nasby wrote:
> 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
onenode simultaneously?
 

A similar comment appeared shortly upthread.  Given a planner and executor
capable of that, we would do so here.  Changing the planner and executor
architecture to support it is its own large, open-ended project.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: recovery_min_apply_delay with a negative value
Next
From: David Fetter
Date:
Subject: Re: Small doc patch about pg_service.conf