On Mon, Feb 20, 2017 at 10:54 AM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > On Sun, Feb 19, 2017 at 2:33 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Fri, Feb 17, 2017 at 11:44 AM, Ashutosh Bapat >> <ashutosh.ba...@enterprisedb.com> wrote: >>> That's true for a partitioned table, but not necessarily for every >>> append relation. Amit's patch is generic for all append relations. If >>> the child plans are joins or subquery segments of set operations, I >>> doubt if the same logic works. It may be better if we throw as many >>> workers (or some function "summing" those up) as specified by those >>> subplans. I guess, we have to use different logic for append relations >>> which are base relations and append relations which are not base >>> relations. >> >> Well, I for one do not believe that if somebody writes a UNION ALL >> with 100 branches, they should get 100 (or 99) workers. Generally >> speaking, the sweet spot for parallel workers on queries we've tested >> so far has been between 1 and 4. It's straining credulity to believe >> that the number that's correct for parallel append is more than an >> order of magnitude larger. Since increasing resource commitment by >> the logarithm of the problem size has worked reasonably well for table >> scans, I believe we should pursue a similar approach here. > > Thanks for that explanation. I makes sense. So, something like this > would work: total number of workers = some function of log(sum of > sizes of relations). The number of workers allotted to each segment > are restricted to the the number of workers chosen by the planner > while planning that segment. The patch takes care of the limit right > now. It needs to incorporate the calculation for total number of > workers for append.
log(sum of sizes of relations) isn't well-defined for a UNION ALL query. -- 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
