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 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 reflect the real parallel overhead. (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) The inadequate default gives more and more slower-then-necessary plans when people are moving to newer PG versions with good parallel 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
