Re: Final Patch for GROUPING SETS
От | Noah Misch |
---|---|
Тема | Re: Final Patch for GROUPING SETS |
Дата | |
Msg-id | 20150103175320.GB2241798@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: Final Patch for GROUPING SETS (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Ответы |
Re: Final Patch for GROUPING SETS
|
Список | 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 по дате отправления: