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<n...@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 node simultaneously? 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
