Re: Rename max_parallel_degree?
David G. Johnston <david.g.johnston@gmail.com>
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Petr Jelinek <petr@2ndquadrant.com>
Cc: Jim Nasby <Jim.Nasby@bluetreble.com>, Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@2ndquadrant.com>, Josh berkus <josh@agliodbs.com>,
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Peter Geoghegan <pg@heroku.com>, Noah Misch <noah@leadboat.com>, David Rowley <david.rowley@2ndquadrant.com>,
Amit Kapila <amit.kapila16@gmail.com>, Magnus Hagander <magnus@hagander.net>, Bruce Momjian <bruce@momjian.us>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2016-06-01T15:55:16Z
Lists: pgsql-hackers
On Wed, Jun 1, 2016 at 11:45 AM, Petr Jelinek <petr@2ndquadrant.com> wrote: > That GUC also controls worker processes that are started by extensions, > not just ones that parallel query starts. This is btw one thing I don't > like at all about how the current limits work, the parallel query will > fight for workers with extensions because they share the same limit. Given that this models reality the GUC is doing its job. Now, maybe we need additional knobs to give the end-user the ability to influence how those fights will turn out. But as far as a high-level setting goes max_worker_processes seems to fit the bill - and apparently fits within our existing cluster options naming convention. Parallel query uses workers to assist in query execution. Background tasks use workers during execution. Others..... David J.