Re: increased max_parallel_workers_per_gather results in fewer workers?

Hi Philip,

> On 4. Jun 2020, at 00:23, Philip Semanchuk <philip(at)americanefficient(dot)com> wrote:
>
>> I guess you should show an explain analyze, specifically "Workers
>> Planned/Launched", maybe by linking to explain.depesz.com
>
> Out of an abundance of caution, our company has a policy of not pasting our plans to public servers. However, I can confirm that when I set max_parallel_workers_per_gather > 4 and the runtime increases, this is what’s in the EXPLAIN ANALYZE output:
>
> Workers Planned: 1
> Workers Launched: 1

Can you please verify the amount of max_parallel_workers and max_worker_processes? It should be roughly max_worker_processes > max_parallel_workers > max_parallel_workers_per_gather, for instance:

max_worker_processes = 24
max_parallel_workers = 18
max_parallel_workers_per_gather = 6

Also, there are more configuration settings related to parallel queries you might want to look into. Most notably:

parallel_setup_cost
parallel_tuple_cost
min_parallel_table_scan_size

Especially the last one is a typical dealbreaker, you can try to set it to 0 for the beginning. Good starters for the others are 500 and 0.1 respectively.

> FWIW, the Planning Time reported in EXPLAIN ANALYZE output doesn’t vary significantly, only from 411-443ms, and the variation within that range correlates only very weakly with max_parallel_workers_per_gather.

It can happen, that more parallelism does not help the query but slows it down beyond a specific amount of parallel workers. You can see this in EXPLAIN when there is for instance a BITMAP HEAP INDEX SCAN or similar involved.

Cheers,
Sebastian