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