From: | Hans Buschmann <buschmann(at)nidsa(dot)net> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | AW: Huge performance penalty with parallel queries in Windows x64 v. Linux x64 |
Date: | 2021-05-04 07:40:32 |
Message-ID: | 1620114038935.30845@nidsa.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 best option 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
From | Date | Subject | |
---|---|---|---|
Next Message | Drouvot, Bertrand | 2021-05-04 08:17:49 | Re: pg_upgrade can result in early wraparound on databases with high transaction load |
Previous Message | Andrew Armstrong | 2021-05-04 03:26:53 | 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) |