Re: Parallel Seq Scan vs kernel read ahead

On Wed, 22 Jul 2020 at 18:17, k(dot)jamison(at)fujitsu(dot)com
<k(dot)jamison(at)fujitsu(dot)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