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

Поиск
Список
Период
Сортировка
От Hans Buschmann
Тема AW: Huge performance penalty with parallel queries in Windows x64 v. Linux x64
Дата
Msg-id 1620114038935.30845@nidsa.net
обсуждение исходный текст
Ответ на Re: Huge performance penalty with parallel queries in Windows x64 v. Linux x64  (Thomas Munro <thomas.munro@gmail.com>)
Ответы Re: Huge performance penalty with parallel queries in Windows x64 v. Linux x64  (Thomas Munro <thomas.munro@gmail.com>)
Список pgsql-general
>No Windows here, but could it be super slow at launching workers?  How
>does a trivial parallel query compare, something like?

>SET force_parallel_mode = on;
>EXPLAIN ANALYZE SELECT 42;

indeed this query takes about 40ms in windows and 7ms on Linux (lowest values).

Due to remoting the machine the reported times vary quite a bit.

The problem seems that this (probably inherent) performance disadvantage of windows is not reflected in the cost model.

This causes little to middle complex queries to prioritize parallel execution on windows which is certainly not the
bestoption in these cases. 

The starting of processes should have an adequate cost penalty to guide the planner in the right direction.

Generally disabling parallel queries seems not a viable option with mixed loads.

Here are the query plans:

                                         QUERY PLAN Windows
--------------------------------------------------------------------------------------------
 Gather  (cost=1000.00..1000.11 rows=1 width=4) (actual time=34.995..38.207 rows=1 loops=1)
   Workers Planned: 1
   Workers Launched: 1
   Single Copy: true
   ->  Result  (cost=0.00..0.01 rows=1 width=4) (actual time=0.004..0.004 rows=1 loops=1)
 Planning Time: 0.016 ms
 Execution Time: 39.136 ms
(7 Zeilen)

                                        QUERY PLAN Linux
------------------------------------------------------------------------------------------
 Gather  (cost=1000.00..1000.11 rows=1 width=4) (actual time=6.864..7.764 rows=1 loops=1)
   Workers Planned: 1
   Workers Launched: 1
   Single Copy: true
   ->  Result  (cost=0.00..0.01 rows=1 width=4) (actual time=0.002..0.003 rows=1 loops=1)
 Planning Time: 0.026 ms
 Execution Time: 7.812 ms
(7 rows)


Hans Buschmann


В списке pgsql-general по дате отправления:

Предыдущее
От: Andrew Armstrong
Дата:
Сообщение: Identified cause of potential pg_upgrade failure on Windows due to OS update adding partial block list of ports 50xxxx (could not connect to server)
Следующее
От: Pól Ua Laoínecháin
Дата:
Сообщение: Re: PostgreSQL, Asynchronous I/O, Buffered I/O and why did fsync-gate not affect Oracle or MySQL?