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
sequentialaccess of 1000 pages, which normally is faster from buffer cache on modern hardware.
For Windows, these costs are much higher, so I would propose to set the default to at least 10000, perhaps 25000 to
reflectthe real parallel overhead.
(BTW: Is this cost multiplied by the real count of workers choosen (max_parallel_workers_per_gather) or only a value
independentof the number of workers?. This would matter in windows-high-parallel scenarios)
The inadequate default gives more and more slower-then-necessary plans when people are moving to newer PG versions with
goodparallel support. For them it's like for me a little surprise, which most won't even notice or remedy nor full
understand.
For bigger installations the knowledge of query tuning is more probable and people can react on their real situation.
Perhaps someone with more knowledge with parallel queries can make some profiling / performance tests to justify my
proposals(e.g. what is the sequential page access equivalent of 40 ms on selected platforms):
New defaults proposal:
-- Linux and comparable architectures with fast process creation:
parallel_setup_cost = 2500
-- Windows
parallel_setup_cost = 25000
Thanks
Hans Buschmann