AW: Huge performance penalty with parallel queries in Windows x64 v. Linux x64 - Mailing list pgsql-general

From Hans Buschmann
Subject AW: Huge performance penalty with parallel queries in Windows x64 v. Linux x64
Date
Msg-id 1620114038935.30845@nidsa.net
Whole thread Raw
In response to Re: Huge performance penalty with parallel queries in Windows x64 v. Linux x64  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Huge performance penalty with parallel queries in Windows x64 v. Linux x64
List 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 by date:

Previous
From: Andrew Armstrong
Date:
Subject: 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)
Next
From: Pól Ua Laoínecháin
Date:
Subject: Re: PostgreSQL, Asynchronous I/O, Buffered I/O and why did fsync-gate not affect Oracle or MySQL?