On Wed, 22 Jul 2020 at 18:17, k.jami...@fujitsu.com <k.jami...@fujitsu.com> wrote: > Even though I read the documentation [1][2] on parallel query, I might not > have > understood it clearly yet. So thank you very much for explaining simpler how > the > relation size, GUCs, and reloption affect the query planner's behavior > So in this test case, I shouldn't force the workers to have same values for > workers > planned and workers launched, is it correct? To just let the optimizer do its > own decision.
What you want to do is force the planner's hand with each test as to how many parallel workers it uses by setting the reloption parallel_workers to the number of workers you want to test. Just make sure the executor has enough workers to launch by setting max_parallel_workers and max_worker_processes to something high enough to conduct the tests without the executor failing to launch any workers. > Maybe the relation size is also small as you mentioned, that the query > optimizer decided > to only use 6 workers in my previous test. So let me see first if the results > would vary > again with the above configuration and testing different values for > parallel_workers. The parallel_worker reloption will overwrite the planner's choice of how many parallel workers to use. Just make sure the executor has enough to use. You'll be able to determine that from the Workers Planned matching Workers Launched. David
