Re: Rename max_parallel_degree? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Rename max_parallel_degree?
Date
Msg-id CA+TgmobzvmZPXDtK8D0GCytwnci+_=Dgqh2fMQbMFZxANMbLeg@mail.gmail.com
Whole thread Raw
In response to Re: Rename max_parallel_degree?  ("Daniel Verite" <daniel@manitou-mail.org>)
Responses Re: Rename max_parallel_degree?  (David Rowley <david.rowley@2ndquadrant.com>)
List pgsql-hackers
On Wed, Apr 27, 2016 at 1:05 PM, Daniel Verite <daniel@manitou-mail.org> wrote:
>         Robert Haas wrote:
>> Of course, we could make this value 1-based rather than 0-based, as
>> Peter Geoghegan suggested a while back.  But as I think I said at the
>> time, I think that's more misleading than helpful.  The leader
>> participates in the parallel plan, but typically does far less of the
>> work beneath the Gather node than the other nodes involved in the
>> query, often almost none.  In short, the leader is special.
>> Pretending that it's just another process involved in the parallel
>> group isn't doing anyone a favor.
>
> FWIW, that's not how it looks from the outside (top or vmstat).
> I'm ignorant about how parallel tasks are assigned in the planner,
> but when trying various values for max_parallel_degree and running
> simple aggregates on large tables on a single 4 core CPU doing
> nothing else, I'm only ever seeing max_parallel_degree+1 processes
> indiscriminately at work, often in the same state (R running or
> D waiting for disk).

Right, but they're probably not doing the SAME work.  You can look at
EXPLAIN (ANALYZE, VERBOSE, BUFFERS) to see.  Of course, all the work
above the Gather node is being done by the leader, but the stuff below
the Gather node often has a bit of participation from the leader, but
is mostly the workers.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pgindent
Next
From: Tom Lane
Date:
Subject: Re: Sync timezone code with upstream release tzcode2016c