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