Hi Philip, > On 4. Jun 2020, at 00:23, Philip Semanchuk <philip@xxxxxxxxxxxxxxxxxxxxx> 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
