JS> While the opportunities for parallelism for queries are
JS> sparse, ...

AP> But there is one exception: we can separate fetching data to be
AP> sorted and sort itself ...

As usual I would recommend that we spend some time on looking at the
experience of other rdbms makers.

For instance Ingres (Ingres' QEF is somewhat similar to our RSE):
http://opensource.ingres.com/projects/ingres/documents/technical/qef
http://www.iua.org.uk/conference/Autumn2004/DougInkster2_1004.pdf

Or Oracle, who seem to do something similar in a convoluted way:
http://www.lc.leidenuniv.nl/awcourse/oracle/server.920/a96524/c20paral
.htm

So there would seem to be all sorts of parallelism conceivable:
- separating out independent sub-streams
- separating out fetch & sort
- (ad-hoc) stream partitioning
- etc.

The Ingres approach of "exchange nodes" looks interesting at first
glance, although it might involve too much time wasted on copying.

Exchange nodes would seem to fit the RSE architecture, and generating
such nodes could possibly be done in a separate optimiser pass,
following the current optimiser phases.

Paul