On Wed, May 5, 2021 at 2:12 PM Thomas Munro wrote:
> It might be interesting to know how that 40ms time scales as you add
> more workers. ...
Another thought: I'd also try tests like that in large databases (ie
large virtual memory) vs small ones, and with and without huge/locked
memory pages co
On Wed, May 5, 2021 at 3:50 AM Hans Buschmann wrote:
> (BTW: Is this cost multiplied by the real count of workers choosen
> (max_parallel_workers_per_gather) or only a value independent of the number
> of workers?. This would matter in windows-high-parallel scenarios)
It's not multiplied:
http
Hans Buschmann writes:
> In my opinion, even for Linux the default for parallel_setup_cost is set too
> low (1000). It should reflect the sequential access of 1000 pages, which
> normally is faster from buffer cache on modern hardware.
I tend to agree with you that the default costs for paralle
Thank you Thomas for pointing me to this GUC which I haven't realized before.
>From the documentation I take that a cost of 1.0 is set for a sequential page
>fetch.
In my opinion, even for Linux the default for parallel_setup_cost is set too
low (1000). It should reflect the sequential access o
On Tue, May 4, 2021 at 7:40 PM Hans Buschmann wrote:
> The problem seems that this (probably inherent) performance disadvantage of
> windows is not reflected in the cost model.
https://www.postgresql.org/docs/13/runtime-config-query.html#GUC-PARALLEL-SETUP-COST
is for that.
It might be interest
>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
On Tue, May 4, 2021 at 4:05 AM Hans Buschmann wrote:
> The main difference is the time shown for the Gather Merge step (65 ms vs. 7
> ms)
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;
E
When developing a solution for a new customer request I created a new query
over the production data.
Despite the relatively low row counts of the involved tables (all < 100k) I
noticed quite a long execution time of about 85 ms to 100 ms.
The explain anaylze plan showed a parallel execution p
