Re: [COMMITTERS] pgsql: Add max_parallel_workers GUC.

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Robert Haas <rhaas(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [COMMITTERS] pgsql: Add max_parallel_workers GUC.
Date: 2016-12-03 02:15:01
Message-ID: F9847DA0-DC8E-45EA-9252-7F7DFC7604DA@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Dec 2, 2016, at 5:45 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> writes:
>>> On 12/2/16 2:34 PM, Robert Haas wrote:
>>> Signs point to "no". It seemed like a good idea to leave some daylight between max_parallel_workers and max_worker_processes, but evidently this wasn't the way to get there. Or else we should just give up on that thought.
>
>> Could the defaults be scaled based on max_connections, with a max on the
>> default?
>
> Might work. We've had very bad luck with GUC variables with
> interdependent defaults, but maybe the user-visible knob could be a
> percentage of max_connections or something like that.

Seems like overkill. Let's just reduce the values a bit.

...Robert

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2016-12-03 16:43:02 Re: [COMMITTERS] pgsql: Add max_parallel_workers GUC.
Previous Message Tom Lane 2016-12-02 22:45:11 Re: [COMMITTERS] pgsql: Add max_parallel_workers GUC.

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2016-12-03 03:04:39 Re: [sqlsmith] Failed assertion in _hash_splitbucket_guts
Previous Message Christian Convey 2016-12-03 02:04:24 Re: Tackling JsonPath support