On 2013-05-13 10:57:39 -0400, Tom Lane wrote: > Noah Misch <n...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
