On Thu, May 4, 2017 at 7:20 PM, David Rowley <david.row...@2ndquadrant.com> wrote: > I ended up writing the attached (which I'd not intended to post until > some time closer to when the doors open for PG11). At the moment it's > basically just a test patch to see how it affects things when we give > workers a bit more to do before they come back to look for more work. > In this case, I've just given them 10 pages to work on, instead of the > 1 that's allocated in 9.6 and v10.
I think that this could benefit parallel sort, beyond the obvious fact that it too must have the contention you describe. We generally are faster at sorting presorted input for all kinds of reasons (e.g., insertion sort fallback for quicksort, merging based on replacement of heap's root item). It follows that it's to our advantage to have parallel tuplesort read multiple pages in a range into a worker at once within the parallel heap scan that feeds workers. The leader, which merges worker runs, may ultimately have to perform fewer comparisons as a result of this, which is where most of the benefit would be. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
