On 05/31/2016 10:30 AM, Tom Lane wrote:
Josh berkus <j...@agliodbs.com> writes:
On 05/31/2016 10:16 AM, Peter Geoghegan wrote:
But the distinction between parallel workers and backends that can
participate in parallel query does need to be user-visible. Worker
processes are a commodity (i.e. the user must consider
max_worker_processes).
It's still WAY simpler to understand "max_parallel is the number of
parallel workers I requested".
Any system where you set it to 2 and get only 1 worker on an idle system
is going to cause endless queries on the mailing lists.
I really think that a GUC named "max_parallel_workers", which in fact
limits the number of workers and not something else, is the way to go.
I agree with Tom here. If we are being pedantic for the sake of being
pedantic we are just causing frustration. The term max_parallel_workers
is simple, easy to understand and accurate enough.
Sincerely,
JD
--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
