how does PostgreSQL determine how many parallel processes to start

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

how does PostgreSQL determine how many parallel processes to start

Luca Ferrari-2
Hi all,
I know that parallel processes can be limited by
max_parallel_workers_per_gather and max_parallel_workers, as well as
the condition to consider a parallel plan is min_table_scan_size (and
index). But I would like to understand, once a table has been
considered for a parallel plan, and there is room for other workers,
how will PostgreSQL decide to start another process?

Thanks,
Luca


Reply | Threaded
Open this post in threaded view
|

Re: how does PostgreSQL determine how many parallel processes to start

Laurenz Albe
On Fri, 2021-02-19 at 10:38 +0100, Luca Ferrari wrote:
> I know that parallel processes can be limited by
> max_parallel_workers_per_gather and max_parallel_workers, as well as
> the condition to consider a parallel plan is min_table_scan_size (and
> index). But I would like to understand, once a table has been
> considered for a parallel plan, and there is room for other workers,
> how will PostgreSQL decide to start another process?

During planning, it will generate parallel and non-parallel plans
and take the one it estimates to be cheapest.

At execution time, PostgreSQL will use as many of the planned workers
as are currently available (max_parallel_workers).

Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com



Reply | Threaded
Open this post in threaded view
|

Re: how does PostgreSQL determine how many parallel processes to start

Luca Ferrari-2
On Fri, Feb 19, 2021 at 10:43 AM Laurenz Albe <[hidden email]> wrote:
> At execution time, PostgreSQL will use as many of the planned workers
> as are currently available (max_parallel_workers).

Thanks, but just to make it clear, assuming I execute almost
simultanously two identical queries that can be therefore be
parallelized, does that mean that the first one will be executed with
the max available parallele capacity and the second will "starve" on
parllelism being executed sequentially. Is this correct?
As a consequence to that, this also could mean that a query over a
small table could take more advanatge (in parallel sense) than a scan
on a larger table that was issued just a moment after (assuming both
table can be scanned in parallel), right?

Luca


Reply | Threaded
Open this post in threaded view
|

Re: how does PostgreSQL determine how many parallel processes to start

Laurenz Albe
On Fri, 2021-02-19 at 11:21 +0100, Luca Ferrari wrote:

> > At execution time, PostgreSQL will use as many of the planned workers
> > as are currently available (max_parallel_workers).
>
> Thanks, but just to make it clear, assuming I execute almost
> simultanously two identical queries that can be therefore be
> parallelized, does that mean that the first one will be executed with
> the max available parallele capacity and the second will "starve" on
> parllelism being executed sequentially. Is this correct?
> As a consequence to that, this also could mean that a query over a
> small table could take more advanatge (in parallel sense) than a scan
> on a larger table that was issued just a moment after (assuming both
> table can be scanned in parallel), right?

Precisely.  That is why you have "max_parallel_workers_per_gather"
to limit the number of parallel workers available to a single query.

Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com