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
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
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
