On 05/31/2016 11:10 AM, Tom Lane wrote: > Josh berkus <j...@agliodbs.com> writes: >> Is there a thread on how we determined this default of 2? I can't find >> one under likely search terms. > > The 9.6 open-items list cites > > https://www.postgresql.org/message-id/flat/20160420174631.3qjjhpwsvvx5b...@alap3.anarazel.de
Looks like we didn't decide for the release, just the beta. I can see two ways to go for the final release: 1. Ship with max_parallel_X = 2 (or similar) and a very low max_worker_processes (e.g. 4). 2. Ship with max_parallel_X = 1 (or 0, depending), and with a generous max_worker_processes (e.g. 16). Argument in favor of (1): we want parallelism to work out of the gate for users running on low-concurrency systems. These settings would let some parallelism happen immediately, without overwhelming a 4-to-8-core system/vm. Tuning for the user would then be fairly easy, as we could just tell them "set max_worker_processes to half the number of cores you have". Argument in favor of (2): parallelism is potentially risky for .0, and as a result we want it disabled unless users choose to enable it. Also, defaulting to off lets users make more use of the parallel_degree table attribute to just enable parallelism on select tables. Thoughts? -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
