Re: Rename max_parallel_degree? - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Rename max_parallel_degree?
Date
Msg-id CAM3SWZQS9idryPMzUZ7UOHgKT-5-qzJAM88BBHhfiae4NrDEmg@mail.gmail.com
Whole thread Raw
In response to Re: Rename max_parallel_degree?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Rename max_parallel_degree?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Thu, Jun 9, 2016 at 7:04 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> OK, I pushed this after re-reviewing it and fixing a number of
> oversights.  There remains only the task of adding max_parallel_degree
> as a system-wide limit (as opposed to max_parallel_degree now
> max_parallel_workers_per_gather which is a per-Gather limit), which
> I'm going to argue should be a new open item and not necessarily one
> that I have to own myself.  I would like to take care of it, but I
> will not put it ahead of fixing actual defects and I will not promise
> to have it done in time for 9.6.

I am in favor of having something similar to
max_parallel_workers_per_gather for utility statements like CREATE
INDEX. That will need a cost model, at least where the DBA isn't
explicit about the number of workers to use.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Parallel safety tagging of extension functions
Next
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted