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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers