Re: Huge performance penalty with parallel queries in Windows x64 v. Linux x64

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Hans Buschmann <buschmann(at)nidsa(dot)net>
Cc: "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Huge performance penalty with parallel queries in Windows x64 v. Linux x64
Date: 2021-05-05 02:12:40
Message-ID: CA+hUKG+oi5gXE_fXOYMp4um=OZO8wc0uD15XAj2V_g9Rj_gRQA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, May 5, 2021 at 3:50 AM Hans Buschmann <buschmann(at)nidsa(dot)net> wrote:
> (BTW: Is this cost multiplied by the real count of workers choosen (max_parallel_workers_per_gather) or only a value independent of the number of workers?. This would matter in windows-high-parallel scenarios)

It's not multiplied:

https://github.com/postgres/postgres/blob/50e17ad281b8d1c1b410c9833955bc80fbad4078/src/backend/optimizer/path/costsize.c#L398

It might be interesting to know how that 40ms time scales as you add
more workers. For what it's worth, I see that the following query
takes around about ~6ms + ~1.5ms per worker on my FreeBSD machine, and
on Linux it's harder to pin down, varying a lot, usually a bit slower
(sorry I didn't have time to do proper statistics).

create table t ();
alter table t set (parallel_workers=8);
set min_parallel_table_scan_size = 0;
set parallel_setup_cost = 0;
set parallel_tuple_cost = 0;

set max_parallel_workers_per_gather = 1;
explain analyze select count(*) from t;

...

set max_parallel_workers_per_gather = 7;
explain analyze select count(*) from t;

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Thomas Munro 2021-05-05 02:27:40 Re: Huge performance penalty with parallel queries in Windows x64 v. Linux x64
Previous Message Ian Lawrence Barwick 2021-05-05 02:04:38 Re: Error creating postgres extensions