Re: Rename max_parallel_degree?
От | David G. Johnston |
---|---|
Тема | Re: Rename max_parallel_degree? |
Дата | |
Msg-id | CAKFQuwYjeEmM1yi7C=7hOa72AP9trCUPSKML_eHuNAoYnxg6Sw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Rename max_parallel_degree? (Josh berkus <josh@agliodbs.com>) |
Список | pgsql-hackers |
On 05/31/2016 11:17 AM, Peter Eisentraut wrote:
> On 5/31/16 2:02 PM, Josh berkus wrote:
>> I get where you're coming from, but I think Haas's query plan output is
>> going to show us the confusion we're going to get. So we need to either
>> change the parameter, the explain output, or brace ourselves for endless
>> repeated questions.
>
> Changing the explain output doesn't sound so bad to me.
>
> The users' problem is that the parameter setting ought to match the
> EXPLAIN output.
>
> The developers' problem is that the EXPLAIN output actually corresponds
> to leader + (N-1) workers internally.
>
> I think we can hope that developers are going to be less confused about
> that than users.
Makes sense.
One more consistency question: what's the effect of running out of
max_parallel_workers?
That is, say max_parallel_workers is set to 10, and 8 are already
allocated. If I ask for max_parallel_X = 4, how many cores to I use?
Presumably the leader isn't counted towards max_parallel_workers?
You'd have three O/S processes - the one dedicated to your session and you'd pick up two additional processes from the worker pool to assist.
How the O/S assigns those to cores is outside PostgreSQL's jurisdiction.
David J.
В списке pgsql-hackers по дате отправления: