Re: Huge performance penalty with parallel queries in Windows x64 v. Linux x64
От | Thomas Munro |
---|---|
Тема | Re: Huge performance penalty with parallel queries in Windows x64 v. Linux x64 |
Дата | |
Msg-id | CA+hUKG+oi5gXE_fXOYMp4um=OZO8wc0uD15XAj2V_g9Rj_gRQA@mail.gmail.com обсуждение исходный текст |
Ответ на | AW: Huge performance penalty with parallel queries in Windows x64 v. Linux x64 (Hans Buschmann <buschmann@nidsa.net>) |
Ответы |
Re: Huge performance penalty with parallel queries in Windows x64 v. Linux x64
|
Список | pgsql-general |
On Wed, May 5, 2021 at 3:50 AM Hans Buschmann <buschmann@nidsa.net> wrote: > (BTW: Is this cost multiplied by the real count of workers choosen (max_parallel_workers_per_gather) or only a value independentof 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;
В списке pgsql-general по дате отправления: