Re: Rename max_parallel_degree?
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Petr Jelinek <petr@2ndquadrant.com>,
"David G. Johnston" <david.g.johnston@gmail.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 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-03T04:33:02Z
Lists: pgsql-hackers
On 6/3/16 12:21 AM, Petr Jelinek wrote: > On 01/06/16 17:55, David G. Johnston wrote: >> On Wed, Jun 1, 2016 at 11:45 AM, Petr Jelinek <petr@2ndquadrant.com >> <mailto: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. > > Agreed, my point is that I think we do need additional knob. We need one knob to control how many process slots to create at server start, and then a bunch of sliders to control how to allocate those between regular connections, superuser connections, replication, autovacuum, parallel workers, background workers (by tag/label/group), and so on. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services