Re: Choosing parallel_degree

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Julien Rouhaud <julien(dot)rouhaud(at)dalibo(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, James Sewell <james(dot)sewell(at)lisasoft(dot)com>
Subject: Re: Choosing parallel_degree
Date: 2016-03-17 23:56:58
Message-ID: 17487.1458259018@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Julien Rouhaud <julien(dot)rouhaud(at)dalibo(dot)com> writes:
> Shouldn't we also check "parallel_degree < max_worker_process" ?

> There's no need to compute any further than that. I think the best fix
> would be to add a CheckHook or AssignHook on max_parallel_degree GUC to
> make sure it's not more than max_worker_process.

Please, let's not go there. Interdependent checks on GUC values are far
harder to get right than you think. It's far better to design the GUC
specifications so that it doesn't matter.

For an example whereof I speak, check the sordid history of commit
ee1e5662d8d83307 ("Auto-tune effective_cache size to be 4x shared
buffers"), which eventually got reverted after a huge amount of thrashing
trying to make it work consistently. Admittedly, that was trying to make
the default value of GUC X depend on GUC Y, but I think checking whether
X <= Y would have many of the same problems. The core issue is you don't
know which one's going to get set first.

In this particular case I think it'd be fine to document that the
effective amount of parallelism is Min(parallel_degree,max_worker_process).

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chapman Flack 2016-03-18 00:01:20 Re: Make primnodes.h gender neutral
Previous Message Marisa Emerson 2016-03-17 23:49:59 Re: Proposal: BSD Authentication support