Re: Parallel Sort

On 2013-05-13 10:57:39 -0400, Tom Lane wrote:
> Noah Misch <noah@leadboat.com> writes:
> > Each worker needs to make SnapshotNow visibility decisions coherent with the
> > master.  For sorting, this allows us to look up comparison functions, even
> > when the current transaction created or modified those functions.  This will
> > also be an essential building block for any parallelism project that consults
> > user tables.  Implementing this means copying the subtransaction stack and the
> > combocid hash to each worker.
> 
> > [ ... and GUC settings, and who knows what else ... ]
> 
> This approach seems to me to be likely to guarantee that the startup
> overhead for any parallel sort is so large that only fantastically
> enormous sorts will come out ahead.

I think if this is the way to go - and I am not sure it is - we need to
use some worker pool that then are (re-)used everytime someone needs to
do a sort. Which would be easier if backends could switch databases...

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services