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

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

In response to

Responses

Browse pgsql-general by date

  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)