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).
Also when looking at exec times, for a CPU-bound sample query, I get
for instance the results below, when increasing parallelism one step
at a time, on a 4-core CPU.
I've checked with EXPLAIN that the planner allocates each time
a number of workers that's exactly equal to max_parallel_degree.
("Workers Planned" under the Gather node).
mp_degree | exec_time | speedup (against degree=0)
-----------+-----------+--------- 0 | 10850.835 | 1.00 1 | 5833.208 | 1.86 2 | 3990.144 | 2.72 3 | 3165.606
| 3.43 4 | 3315.153 | 3.27 5 | 3333.931 | 3.25 6 | 3354.995 | 3.23
If the leader didn't do much work here, how would degree=1 produce
such a speedup (1.86) ?
There's also the fact that allowing 4 workers does not help compared
to 3, even though there are 4 cores here. Again, doesn't it make sense
only if the leader is as important as the workers in terms of CPU
usage?
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
