Re: Rename max_parallel_degree?
От | Peter Eisentraut |
---|---|
Тема | Re: Rename max_parallel_degree? |
Дата | |
Msg-id | a2fffd92-6e59-a4eb-dd85-c5865ebca1a0@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Rename max_parallel_degree? (Petr Jelinek <petr@2ndquadrant.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: