On Sat, Dec 3, 2016 at 11:43 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Dec 2, 2016, at 5:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> 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.
>
> Agreed. How about max_worker_processes = 8 as before, with
> max_parallel_workers of maybe 6? Or just set them both to 8.
> I'm not sure that the out-of-the-box configuration needs to
> leave backend slots locked down for non-parallel worker processes.
> Any such process would require manual configuration anyway no?
Sure, you'd have to arrange to load the relevant module somehow. It
would be nicer if we didn't have to require additional configuration
beyond that, but I'm not prepared to ask BF owners to reconfigure
their systems just for that marginal advantage, so I think we'll have
to live with this for now.
I pushed a commit backing out the increased default, which I
originally suggested. Mea culpa.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company