Re: Parallel Seq Scan vs kernel read ahead - Mailing list pgsql-hackers

From David Rowley
Subject Re: Parallel Seq Scan vs kernel read ahead
Date
Msg-id CAApHDvrrdd-d=cRmp6gn2oBNK=mND4oJkVvgy9ZYzgKTfz=Hhg@mail.gmail.com
Whole thread Raw
In response to Re: Parallel Seq Scan vs kernel read ahead  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Wed, 22 Jul 2020 at 18:17, k.jamison@fujitsu.com
<k.jamison@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



pgsql-hackers by date:

Previous
From: Georgios
Date:
Subject: Re: Using Valgrind to detect faulty buffer accesses (no pin or buffer content lock held)
Next
From: "Andrey V. Lepikhov"
Date:
Subject: Re: [POC] Fast COPY FROM command for the table with foreign partitions