On Sat, Aug 5, 2017 at 6:17 PM, Peter Geoghegan <p...@bowt.ie> wrote: > 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.
On the other hand, it could hurt Gather Merge for essentially symmetric reasons - Gather Merge works best if all the tuples are in roughly the same range of values. Otherwise the work isn't equally distributed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
