Re: [HACKERS] Rename max_parallel_degree?

On Fri, Dec 02, 2016 at 07:45:56AM -0500, Robert Haas wrote: > On Thu, Dec 1, 2016 at 10:07 PM, Haribabu Kommi > wrote: > > From the recent mails, it is not clear to me what is the status of this > > patch. > > moved to next CF with "needs review" state. Please feel free

Re: [HACKERS] Rename max_parallel_degree?

On Thu, Dec 1, 2016 at 10:07 PM, Haribabu Kommi wrote: > From the recent mails, it is not clear to me what is the status of this > patch. > moved to next CF with "needs review" state. Please feel free to update > the status. I have committed this patch. And updated the

Re: [HACKERS] Rename max_parallel_degree?

On Thu, Oct 27, 2016 at 3:38 AM, Robert Haas wrote: > On Mon, Oct 24, 2016 at 4:04 PM, Peter Eisentraut > wrote: > > On 10/12/16 7:58 PM, Robert Haas wrote: > >> I don't think it's wrong that the handling is done there, though. The > >>

Re: [HACKERS] Rename max_parallel_degree?

On Mon, Oct 24, 2016 at 4:04 PM, Peter Eisentraut wrote: > On 10/12/16 7:58 PM, Robert Haas wrote: >> I don't think it's wrong that the handling is done there, though. The >> process that is registering the background worker is well-placed to >> check whether

Re: [HACKERS] Rename max_parallel_degree?

On Wed, Oct 26, 2016 at 5:54 PM, Robert Haas wrote: > On Mon, Oct 24, 2016 at 3:48 AM, Amit Kapila wrote: >> On Thu, Oct 13, 2016 at 5:28 AM, Robert Haas wrote: >>> On Wed, Oct 12, 2016 at 8:13 AM, Peter Eisentraut >>>

Re: [HACKERS] Rename max_parallel_degree?

On Mon, Oct 24, 2016 at 3:48 AM, Amit Kapila wrote: > On Thu, Oct 13, 2016 at 5:28 AM, Robert Haas wrote: >> On Wed, Oct 12, 2016 at 8:13 AM, Peter Eisentraut >> wrote: >>> On 10/4/16 10:16 AM, Julien Rouhaud

Re: [HACKERS] Rename max_parallel_degree?

On 10/12/16 7:58 PM, Robert Haas wrote: > I don't think it's wrong that the handling is done there, though. The > process that is registering the background worker is well-placed to > check whether there are already too many, and if it does not then the > slot is consumed at least temporarily

Re: [HACKERS] Rename max_parallel_degree?

On Thu, Oct 13, 2016 at 5:28 AM, Robert Haas wrote: > On Wed, Oct 12, 2016 at 8:13 AM, Peter Eisentraut > wrote: >> On 10/4/16 10:16 AM, Julien Rouhaud wrote: >>> Please find attached v9 of the patch, adding the parallel worker class >>>

Re: [HACKERS] Rename max_parallel_degree?

On Wed, Oct 12, 2016 at 8:13 AM, Peter Eisentraut wrote: > On 10/4/16 10:16 AM, Julien Rouhaud wrote: >> Please find attached v9 of the patch, adding the parallel worker class >> and changing max_worker_processes default to 16 and max_parallel_workers >> to 8. I

Re: [HACKERS] Rename max_parallel_degree?

On 10/4/16 10:16 AM, Julien Rouhaud wrote: > Please find attached v9 of the patch, adding the parallel worker class > and changing max_worker_processes default to 16 and max_parallel_workers > to 8. I also added Amit's explanation for the need of a write barrier > in ForgetBackgroundWorker().

Re: [HACKERS] Rename max_parallel_degree?

On 03/10/2016 21:27, Robert Haas wrote: > On Fri, Sep 30, 2016 at 12:23 PM, Julien Rouhaud > wrote: >> I've already fixed every other issues mentioned upthread, but I'm facing >> a problem for this one. Assuming that the bgworker classes are supposed >> to be mutually

Re: [HACKERS] Rename max_parallel_degree?

On Fri, Sep 30, 2016 at 12:23 PM, Julien Rouhaud wrote: > I've already fixed every other issues mentioned upthread, but I'm facing > a problem for this one. Assuming that the bgworker classes are supposed > to be mutually exclusive, I don't see a simple and clean way

Re: [HACKERS] Rename max_parallel_degree?

On Sat, Oct 1, 2016 at 1:23 AM, Julien Rouhaud wrote: > On 23/09/2016 21:10, Robert Haas wrote: >> On Fri, Sep 23, 2016 at 8:54 AM, Peter Eisentraut >> wrote: >>> On 9/20/16 4:07 PM, Robert Haas wrote: No, I'm assuming that the

Re: [HACKERS] Rename max_parallel_degree?

On 23/09/2016 21:10, Robert Haas wrote: > On Fri, Sep 23, 2016 at 8:54 AM, Peter Eisentraut > wrote: >> On 9/20/16 4:07 PM, Robert Haas wrote: >>> No, I'm assuming that the classes would be built-in. A string tag >>> seems like over-engineering to me,

Re: [HACKERS] Rename max_parallel_degree?

On Fri, Sep 23, 2016 at 8:54 AM, Peter Eisentraut wrote: > On 9/20/16 4:07 PM, Robert Haas wrote: >> No, I'm assuming that the classes would be built-in. A string tag >> seems like over-engineering to me, particularly because the postmaster >> needs to switch on

Re: [HACKERS] Rename max_parallel_degree?

On 9/20/16 4:07 PM, Robert Haas wrote: > No, I'm assuming that the classes would be built-in. A string tag > seems like over-engineering to me, particularly because the postmaster > needs to switch on the tag, and we need to be very careful about the > degree to which the postmaster trusts the

Re: [HACKERS] Rename max_parallel_degree?

On Tue, Sep 20, 2016 at 3:31 PM, Peter Eisentraut wrote: > On 9/20/16 11:47 AM, Robert Haas wrote: >> #define BGWORKER_CLASS_MASK 0x00f0 >> #define BGWORKER_CLASS_PARALLEL 0x0010 >> /* add additional bgworker classes here */ >>> > >>> > Unless

Re: [HACKERS] Rename max_parallel_degree?

On 9/20/16 11:47 AM, Robert Haas wrote: >>> >> #define BGWORKER_CLASS_MASK 0x00f0 >>> >> #define BGWORKER_CLASS_PARALLEL 0x0010 >>> >> /* add additional bgworker classes here */ >> > >> > Unless we have a mechanism that makes use of this somehow, this attempt >> > at categorizing might be

Re: [HACKERS] Rename max_parallel_degree?

On 20/09/16 17:47, Robert Haas wrote: > On Tue, Sep 20, 2016 at 11:27 AM, Peter Eisentraut > wrote: >> On 9/19/16 2:18 PM, Robert Haas wrote: >>> I suggest that we make it part of bgw_flags, but use a bitmask for it, >>> like this: >>> >>> #define

Re: [HACKERS] Rename max_parallel_degree?

On Tue, Sep 20, 2016 at 11:27 AM, Peter Eisentraut wrote: > On 9/19/16 2:18 PM, Robert Haas wrote: >> I suggest that we make it part of bgw_flags, but use a bitmask for it, >> like this: >> >> #define BGWORKER_CLASS_MASK 0x00f0 >> #define

Re: [HACKERS] Rename max_parallel_degree?

On 9/19/16 2:18 PM, Robert Haas wrote: > I suggest that we make it part of bgw_flags, but use a bitmask for it, > like this: > > #define BGWORKER_CLASS_MASK 0x00f0 > #define BGWORKER_CLASS_PARALLEL 0x0010 > /* add additional bgworker classes here */ Unless we have a mechanism that makes use

Re: [HACKERS] Rename max_parallel_degree?

On Sat, Sep 17, 2016 at 2:40 AM, Amit Kapila wrote: > On Fri, Sep 16, 2016 at 11:54 PM, Robert Haas wrote: >> >> + /* >> +* We need a write barrier to make sure the update of >> +* parallel_terminate_count is done before the

Re: [HACKERS] Rename max_parallel_degree?

On Fri, Sep 16, 2016 at 3:53 PM, Julien Rouhaud wrote: > That's fine by me. Should this be done (if there's no objection) in the > same patch, or in another one? I'd say "same patch". >> I'd suggest renaming the "parallel" flag to BackgroundWorkerSlot to >>

Re: [HACKERS] Rename max_parallel_degree?

On Fri, Sep 16, 2016 at 11:54 PM, Robert Haas wrote: > > + /* > +* We need a write barrier to make sure the update of > +* parallel_terminate_count is done before the store to in_use > +*/ > > Does the order actually matter here? > I think so.

Re: [HACKERS] Rename max_parallel_degree?

On 16/09/2016 20:24, Robert Haas wrote: > On Wed, Jun 29, 2016 at 10:46 PM, Amit Kapila wrote: >> Your patch looks good to me and is ready for a committer's look. >> >> Notes for committer - >> a. Verify if description of newly added Guc max_parallel_workers looks >> okay

Re: [HACKERS] Rename max_parallel_degree?

On Wed, Jun 29, 2016 at 10:46 PM, Amit Kapila wrote: > Your patch looks good to me and is ready for a committer's look. > > Notes for committer - > a. Verify if description of newly added Guc max_parallel_workers looks > okay to you, me and Julien are not in 100%

Re: [HACKERS] Rename max_parallel_degree?

On Wed, Jun 29, 2016 at 11:54 AM, Julien Rouhaud wrote: > On 29/06/2016 06:29, Amit Kapila wrote: >> On Wed, Jun 29, 2016 at 2:57 AM, Julien Rouhaud >> wrote: >>> >>> Thanks a lot for the help! >>> >>> PFA v6 which should fix all the issues

Re: [HACKERS] Rename max_parallel_degree?

On 29/06/2016 08:51, Amit Kapila wrote: > On Wed, Jun 29, 2016 at 11:54 AM, Julien Rouhaud > wrote: >> Or should we allow setting it to -1 for instance to disable the limit? >> > > By disabling the limit, do you mean to say that only > max_parallel_workers_per_gather

Re: [HACKERS] Rename max_parallel_degree?

On Wed, Jun 29, 2016 at 11:54 AM, Julien Rouhaud wrote: > Or should we allow setting it to -1 for instance to disable the limit? > By disabling the limit, do you mean to say that only max_parallel_workers_per_gather will determine the workers required or something

Re: [HACKERS] Rename max_parallel_degree?

On 29/06/2016 06:29, Amit Kapila wrote: > On Wed, Jun 29, 2016 at 2:57 AM, Julien Rouhaud > wrote: >> >> Thanks a lot for the help! >> >> PFA v6 which should fix all the issues mentioned. > > Couple of minor suggestions. > > - . Note that the requested > +

Re: [HACKERS] Rename max_parallel_degree?

On Wed, Jun 29, 2016 at 2:57 AM, Julien Rouhaud wrote: > > Thanks a lot for the help! > > PFA v6 which should fix all the issues mentioned. Couple of minor suggestions. - . Note that the requested + , limited by + . Note that the requested

Re: [HACKERS] Rename max_parallel_degree?

On 28/06/2016 04:44, Amit Kapila wrote: > On Mon, Jun 27, 2016 at 10:35 PM, Julien Rouhaud >> >> There's already a pg_memory_barrier() call in >> BackgroundWorkerStateChange(), to avoid reordering the notify_pid load. >> Couldn't we use it to also make sure the parallel_terminate_count >>

Re: [HACKERS] Rename max_parallel_degree?

On Mon, Jun 27, 2016 at 10:35 PM, Julien Rouhaud wrote: > On 27/06/2016 07:18, Amit Kapila wrote: >> On Mon, Jun 27, 2016 at 10:21 AM, Amit Kapila >> wrote: >>> >>> I think as the parallel_terminate_count is only modified by postmaster >>> and

Re: [HACKERS] Rename max_parallel_degree?

On 27/06/2016 07:18, Amit Kapila wrote: > On Mon, Jun 27, 2016 at 10:21 AM, Amit Kapila wrote: >> >> I think as the parallel_terminate_count is only modified by postmaster >> and read by other processes, such an operation will be considered >> atomic. We don't need to

Re: [HACKERS] Rename max_parallel_degree?

On Mon, Jun 27, 2016 at 10:21 AM, Amit Kapila wrote: > On Sun, Jun 26, 2016 at 3:57 PM, Julien Rouhaud > wrote: >> On 26/06/2016 08:37, Amit Kapila wrote: >>> >>> @@ -370,6 +379,8 @@ ForgetBackgroundWorker(slist_mutable_iter *cur) >>>

Re: [HACKERS] Rename max_parallel_degree?

On Sun, Jun 26, 2016 at 3:57 PM, Julien Rouhaud wrote: > On 26/06/2016 08:37, Amit Kapila wrote: >> >> @@ -370,6 +379,8 @@ ForgetBackgroundWorker(slist_mutable_iter *cur) >> Assert(rw->rw_shmem_slot < >> max_worker_processes); >> slot = >slot[rw->rw_shmem_slot]; >>

Re: [HACKERS] Rename max_parallel_degree?

On 26/06/2016 08:37, Amit Kapila wrote: > On Sat, Jun 25, 2016 at 2:27 PM, Julien Rouhaud > wrote: >>> >> >> It's better thanks. Should we document somewhere the link between this >> parameter and custom dynamic background workers or is it pretty >> self-explanatory?

Re: [HACKERS] Rename max_parallel_degree?

On Sat, Jun 25, 2016 at 2:27 PM, Julien Rouhaud wrote: > On 25/06/2016 09:33, Amit Kapila wrote: >> On Wed, Jun 15, 2016 at 11:43 PM, Julien Rouhaud >> wrote: >>> >>> Attached v4 implements the design you suggested, I hope everything's ok.

Re: [HACKERS] Rename max_parallel_degree?

On 25/06/2016 09:33, Amit Kapila wrote: > On Wed, Jun 15, 2016 at 11:43 PM, Julien Rouhaud > wrote: >> >> Attached v4 implements the design you suggested, I hope everything's ok. >> > > Few review comments: > Thanks for the review. > 1. > + if (parallel &&

Re: [HACKERS] Rename max_parallel_degree?

On Wed, Jun 15, 2016 at 11:43 PM, Julien Rouhaud wrote: > > Attached v4 implements the design you suggested, I hope everything's ok. > Few review comments: 1. + if (parallel && (BackgroundWorkerData->parallel_register_count - +

Re: [HACKERS] Rename max_parallel_degree?

On 15/06/2016 18:14, Julien Rouhaud wrote: > On 15/06/2016 17:49, Robert Haas wrote: >> On Tue, Jun 14, 2016 at 7:10 AM, Julien Rouhaud >> wrote: I don't entirely like the new logic in RegisterDynamicBackgroundWorker. >>> I wonder if we can't drive this

Re: [HACKERS] Rename max_parallel_degree?

On 15/06/2016 17:49, Robert Haas wrote: > On Tue, Jun 14, 2016 at 7:10 AM, Julien Rouhaud > wrote: >>> I don't entirely like the new logic in >>> RegisterDynamicBackgroundWorker. >> >>> I wonder if we can't drive this off >>> of a couple of counters, instead of having

Re: [HACKERS] Rename max_parallel_degree?

On Tue, Jun 14, 2016 at 7:10 AM, Julien Rouhaud wrote: >> I don't entirely like the new logic in >> RegisterDynamicBackgroundWorker. > > I'm not that happy with it too. We can avoid iterating over every slots > if the feature isn't activated though (max_parallel_workers

Re: [HACKERS] Rename max_parallel_degree?

On Tue, Jun 14, 2016 at 12:16 PM, Tom Lane wrote: > Robert Haas writes: >> Of course, it would be nice if we could make these counters 64-bit >> integers, but we can't, because we don't rely on 64-bit reads and >> writes to be atomic on all platforms.

Re: [HACKERS] Rename max_parallel_degree?

Robert Haas writes: > Of course, it would be nice if we could make these counters 64-bit > integers, but we can't, because we don't rely on 64-bit reads and > writes to be atomic on all platforms. So instead they'll have to be > uint32. That means they could wrap (if you

Re: [HACKERS] Rename max_parallel_degree?

On 14/06/2016 04:09, Robert Haas wrote: > On Mon, Jun 13, 2016 at 5:42 AM, Julien Rouhaud > wrote: >> Agreed, and fixed in attached v3. > > I don't entirely like the new logic in > RegisterDynamicBackgroundWorker. I'm not that happy with it too. We can avoid iterating

Re: [HACKERS] Rename max_parallel_degree?

On Mon, Jun 13, 2016 at 5:42 AM, Julien Rouhaud wrote: > Agreed, and fixed in attached v3. I don't entirely like the new logic in RegisterDynamicBackgroundWorker. I wonder if we can't drive this off of a couple of counters, instead of having the process registering

Re: [HACKERS] Rename max_parallel_degree?

On 13/06/2016 03:16, Robert Haas wrote: > On Sat, Jun 11, 2016 at 6:24 PM, Julien Rouhaud > wrote: >> On 11/06/2016 23:37, Julien Rouhaud wrote: >>> On 09/06/2016 16:04, Robert Haas wrote: There remains only the task of adding max_parallel_degree as a

Re: [HACKERS] Rename max_parallel_degree?

On Sat, Jun 11, 2016 at 6:24 PM, Julien Rouhaud wrote: > On 11/06/2016 23:37, Julien Rouhaud wrote: >> On 09/06/2016 16:04, Robert Haas wrote: >>> OK, I pushed this after re-reviewing it and fixing a number of >>> oversights. There remains only the task of adding

Re: [HACKERS] Rename max_parallel_degree?

On 11/06/2016 23:37, Julien Rouhaud wrote: > On 09/06/2016 16:04, Robert Haas 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 >>

Re: [HACKERS] Rename max_parallel_degree?

On 09/06/2016 16:04, Robert Haas 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

Re: [HACKERS] Rename max_parallel_degree?

On Thu, Jun 9, 2016 at 6:09 PM, Peter Geoghegan wrote: > On Thu, Jun 9, 2016 at 1:08 PM, Robert Haas wrote: >>> I am in favor of having something similar to >>> max_parallel_workers_per_gather for utility statements like CREATE >>> INDEX. That will need a

Re: [HACKERS] Rename max_parallel_degree?

On Thu, Jun 9, 2016 at 1:08 PM, Robert Haas wrote: >> 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

Re: [HACKERS] Rename max_parallel_degree?

On Thu, Jun 9, 2016 at 2:05 PM, Peter Geoghegan wrote: > On Thu, Jun 9, 2016 at 7:04 AM, Robert Haas 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

Re: [HACKERS] Rename max_parallel_degree?

On Thu, Jun 9, 2016 at 7:04 AM, Robert Haas 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 >

Re: [HACKERS] Rename max_parallel_degree?

On Wed, Jun 8, 2016 at 10:18 AM, Tom Lane wrote: > Josh Berkus writes: >> On 06/07/2016 11:01 PM, Robert Haas wrote: >>> Here's a patch change max_parallel_degree to >>> max_parallel_workers_per_gather, and also changing parallel_degree to >>>

Re: [HACKERS] Rename max_parallel_degree?

On Wed, Jun 8, 2016 at 10:41 AM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Jun 8, 2016 at 10:18 AM, Tom Lane wrote: >>> catversion is not relevant to GUC changes. It's not really necessary, >>> because you'd get a clean,

Re: [HACKERS] Rename max_parallel_degree?

Robert Haas writes: > On Wed, Jun 8, 2016 at 10:18 AM, Tom Lane wrote: >> catversion is not relevant to GUC changes. It's not really necessary, >> because you'd get a clean, easily diagnosed and repaired failure during >> postmaster startup anyway.

Re: [HACKERS] Rename max_parallel_degree?

On Wed, Jun 8, 2016 at 10:18 AM, Tom Lane wrote: >>> Note that there is a dump/restore hazard if people have set the >>> parallel_degree reloption on a beta1 install, or used ALTER { USER | >>> DATABASE } .. SET parallel_degree. Can everybody live with that? >>> Should I bump

Re: [HACKERS] Rename max_parallel_degree?

Josh Berkus writes: > On 06/07/2016 11:01 PM, Robert Haas wrote: >> Here's a patch change max_parallel_degree to >> max_parallel_workers_per_gather, and also changing parallel_degree to >> parallel_workers. I haven't tackled adding a separate >> max_parallel_workers, at least

Re: [HACKERS] Rename max_parallel_degree?

On 06/07/2016 11:01 PM, Robert Haas wrote: > On Fri, Jun 3, 2016 at 9:39 AM, Tom Lane wrote: >> Robert Haas writes: >>> I think we should just go with max_parallel_workers for a limit on >>> total parallel workers within max_work_processes, and >>>

Re: [HACKERS] Rename max_parallel_degree?

On Fri, Jun 3, 2016 at 9:39 AM, Tom Lane wrote: > Robert Haas writes: >> I think we should just go with max_parallel_workers for a limit on >> total parallel workers within max_work_processes, and >> max_parallel_workers_per_gather for a per-Gather

Re: [HACKERS] Rename max_parallel_degree?

On 06/02/2016 09:33 PM, Peter Eisentraut wrote: > On 6/3/16 12:21 AM, Petr Jelinek wrote: >> On 01/06/16 17:55, David G. Johnston wrote: >>> On Wed, Jun 1, 2016 at 11:45 AM, Petr Jelinek >> >wrote: >>> >>> That GUC also controls worker

Re: [HACKERS] Rename max_parallel_degree?

Robert Haas writes: > I think we should just go with max_parallel_workers for a limit on > total parallel workers within max_work_processes, and > max_parallel_workers_per_gather for a per-Gather limit. It's slightly > annoying that we may end up renaming the latter GUC,

Re: [HACKERS] Rename max_parallel_degree?

On Fri, Jun 3, 2016 at 8:30 AM, David G. Johnston wrote: > How big is the hazard of future-naming this and documenting the present > limitation? Is the casual user reading explains even going to be aware of > that particular implementation detail? Well, see, the nice

Re: [HACKERS] Rename max_parallel_degree?

On Fri, Jun 3, 2016 at 8:20 AM, Robert Haas wrote: > On Thu, Jun 2, 2016 at 4:35 PM, Josh berkus wrote: > > I was assuming that we would have *both* per-operation and per-statement > > limits. I can see reasons for having both, I can see why power

Re: [HACKERS] Rename max_parallel_degree?

On Thu, Jun 2, 2016 at 4:35 PM, Josh berkus wrote: > I was assuming that we would have *both* per-operation and per-statement > limits. I can see reasons for having both, I can see why power users > would want both, but it's going to be overwhelming to casual users. I don't

Re: [HACKERS] Rename max_parallel_degree?

Robert Haas wrote: > On Wed, Jun 1, 2016 at 5:29 PM, Tom Lane wrote: > > Robert Haas writes: > >> I've largely given up hope of coming up with an alternative that can > >> attract more than one vote and that is also at least mildly accurate, > >> but

Re: [HACKERS] Rename max_parallel_degree?

On 6/3/16 12:21 AM, Petr Jelinek wrote: On 01/06/16 17:55, David G. Johnston wrote: On Wed, Jun 1, 2016 at 11:45 AM, Petr Jelinek >wrote: That GUC also controls worker processes that are started by extensions, not just ones that

Re: [HACKERS] Rename max_parallel_degree?

On 01/06/16 17:55, David G. Johnston wrote: On Wed, Jun 1, 2016 at 11:45 AM, Petr Jelinek >wrote: That GUC also controls worker processes that are started by extensions, not just ones that parallel query starts. This is btw one

Re: [HACKERS] Rename max_parallel_degree?

On 06/02/2016 01:42 PM, David G. Johnston wrote: > ​Are you referring to right now or if we move the goal posts to making > > this a per-statement reservation?​ > > I was assuming that we would have *both* per-operation and per-statement > limits. I can see reasons for having

Re: [HACKERS] Rename max_parallel_degree?

On Thu, Jun 2, 2016 at 4:35 PM, Josh berkus wrote: > On 06/02/2016 01:08 PM, David G. Johnston wrote: > > On Thu, Jun 2, 2016 at 3:52 PM, Josh berkus > >wrote: > > > > On 06/02/2016 08:53 AM, Tom Lane wrote: > > > Josh

Re: [HACKERS] Rename max_parallel_degree?

On 06/02/2016 01:08 PM, David G. Johnston wrote: > On Thu, Jun 2, 2016 at 3:52 PM, Josh berkus >wrote: > > On 06/02/2016 08:53 AM, Tom Lane wrote: > > Josh berkus > writes: > >> On 06/02/2016

Re: [HACKERS] Rename max_parallel_degree?

On Thu, Jun 2, 2016 at 3:52 PM, Josh berkus wrote: > On 06/02/2016 08:53 AM, Tom Lane wrote: > > Josh berkus writes: > >> On 06/02/2016 04:58 AM, Robert Haas wrote: > >>> Well, I think we could drop node, if you like. I think parallel > >>> wouldn't be

Re: [HACKERS] Rename max_parallel_degree?

On 06/02/2016 08:53 AM, Tom Lane wrote: > Josh berkus writes: >> On 06/02/2016 04:58 AM, Robert Haas wrote: >>> Well, I think we could drop node, if you like. I think parallel >>> wouldn't be good to drop, though, because it sounds like we want a >>> global limit on parallel

Re: [HACKERS] Rename max_parallel_degree?

Josh berkus writes: > On 06/02/2016 04:58 AM, Robert Haas wrote: >> Well, I think we could drop node, if you like. I think parallel >> wouldn't be good to drop, though, because it sounds like we want a >> global limit on parallel workers also, and that can't be just >>

Re: [HACKERS] Rename max_parallel_degree?

On 06/02/2016 04:58 AM, Robert Haas wrote: > Well, I think we could drop node, if you like. I think parallel > wouldn't be good to drop, though, because it sounds like we want a > global limit on parallel workers also, and that can't be just > max_workers. So I think we should keep parallel in

Re: [HACKERS] Rename max_parallel_degree?

On Thu, Jun 2, 2016 at 9:59 AM, Tom Lane wrote: > Robert Haas writes: > > Well, I think we could drop node, if you like. I think parallel > > wouldn't be good to drop, though, because it sounds like we want a > > global limit on parallel workers also,

Re: [HACKERS] Rename max_parallel_degree?

Robert Haas writes: > Well, I think we could drop node, if you like. I think parallel > wouldn't be good to drop, though, because it sounds like we want a > global limit on parallel workers also, and that can't be just > max_workers. So I think we should keep parallel in

Re: [HACKERS] Rename max_parallel_degree?

On Wed, Jun 1, 2016 at 5:29 PM, Tom Lane wrote: > Robert Haas writes: >> I've largely given up hope of coming up with an alternative that can >> attract more than one vote and that is also at least mildly accurate, >> but one idea is

Re: [HACKERS] Rename max_parallel_degree?

On 06/01/2016 02:21 PM, Robert Haas wrote: > If you lined up ten people in a room all of whom were competent > database professionals and none of whom knew anything about PostgreSQL > and asked them to guess what a setting called work_mem does and what a > setting called max_parallel_degree does,

Re: [HACKERS] Rename max_parallel_degree?

Robert Haas writes: > I've largely given up hope of coming up with an alternative that can > attract more than one vote and that is also at least mildly accurate, > but one idea is max_parallel_workers_per_gather_node. That will be > totally clear. Given the reference to

Re: [HACKERS] Rename max_parallel_degree?

On Wed, Jun 1, 2016 at 10:10 AM, Tom Lane wrote: > Amit Kapila writes: >> Your explanation is clear, however the name max_parallel_workers makes it >> sound like that parallelising an operation is all about workers. Yes it >> depends a lot on the

Re: [HACKERS] Rename max_parallel_degree?

On Wed, Jun 1, 2016 at 11:45 AM, Petr Jelinek wrote: > That GUC also controls worker processes that are started by extensions, > not just ones that parallel query starts. This is btw one thing I don't > like at all about how the current limits work, the parallel query will

Re: [HACKERS] Rename max_parallel_degree?

On 01/06/16 17:27, Jim Nasby wrote: On 5/31/16 8:48 PM, Robert Haas wrote: On Tue, May 31, 2016 at 5:58 PM, Tom Lane wrote: Alvaro Herrera writes: Robert Haas wrote: I just want to point out that if we change #1, we're breaking postgresql.conf

Re: [HACKERS] Rename max_parallel_degree?

On 5/31/16 8:48 PM, Robert Haas wrote: On Tue, May 31, 2016 at 5:58 PM, Tom Lane wrote: Alvaro Herrera writes: Robert Haas wrote: I just want to point out that if we change #1, we're breaking postgresql.conf compatibility for, IMHO, not a whole

Re: [HACKERS] Rename max_parallel_degree?

Amit Kapila writes: > Your explanation is clear, however the name max_parallel_workers makes it > sound like that parallelising an operation is all about workers. Yes it > depends a lot on the number of workers allocated for parallel operation, > but that is not

Re: [HACKERS] Rename max_parallel_degree?

On Tue, May 31, 2016 at 11:30 PM, Tom Lane wrote: > > I wrote: > > I really think that a GUC named "max_parallel_workers", which in fact > > limits the number of workers and not something else, is the way to go. > > To be concrete, I suggest comparing the attached

Re: [HACKERS] Rename max_parallel_degree?

On Tue, May 31, 2016 at 10:13 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, May 31, 2016 at 10:02 PM, Tom Lane wrote: >>> The reloption does not set an exact value, according to the code: > >> True, max_parallel_degree is an

Re: [HACKERS] Rename max_parallel_degree?

Robert Haas writes: > On Tue, May 31, 2016 at 10:02 PM, Tom Lane wrote: >> The reloption does not set an exact value, according to the code: > True, max_parallel_degree is an overriding limit. But the point is > that, without the reloption, you can't

Re: [HACKERS] Rename max_parallel_degree?

On Tue, May 31, 2016 at 10:02 PM, Tom Lane wrote: > Robert Haas writes: >> Now, this case is a little trickier. If we called it simply >> parallel_degree rather than max_parallel_degree, then it would have >> the same name as the reloption. But the

Re: [HACKERS] Rename max_parallel_degree?

Robert Haas writes: > Now, this case is a little trickier. If we called it simply > parallel_degree rather than max_parallel_degree, then it would have > the same name as the reloption. But the reloption sets an exact > value, and the GUC sets a cap, which is a

Re: [HACKERS] Rename max_parallel_degree?

On Tue, May 31, 2016 at 8:51 PM, Peter Eisentraut wrote: > On 5/31/16 4:04 PM, Tom Lane wrote: >> The name should be closely related to what we use for #3. I could go for >> max_total_parallel_workers for #2 and max_parallel_workers for #3. >> Or maybe

Re: [HACKERS] Rename max_parallel_degree?

On Tue, May 31, 2016 at 5:58 PM, Tom Lane wrote: > Alvaro Herrera writes: >> Robert Haas wrote: >>> I just want to point out that if we change #1, we're breaking >>> postgresql.conf compatibility for, IMHO, not a whole lot of benefit. >>> I'd just

Re: [HACKERS] Rename max_parallel_degree?

On 5/31/16 4:04 PM, Tom Lane wrote: The name should be closely related to what we use for #3. I could go for max_total_parallel_workers for #2 and max_parallel_workers for #3. Or maybe max_parallel_workers_total? Most cluster-wide settings like this are named max_something (max_connections,

Re: [HACKERS] Rename max_parallel_degree?

Alvaro Herrera writes: > Robert Haas wrote: >> I just want to point out that if we change #1, we're breaking >> postgresql.conf compatibility for, IMHO, not a whole lot of benefit. >> I'd just leave it alone. > We can add the old name as a synonym in guc.c to maintain

Re: [HACKERS] Rename max_parallel_degree?

On Tue, May 31, 2016 at 4:12 PM, Robert Haas wrote: > On Tue, May 31, 2016 at 4:04 PM, Tom Lane wrote: > > Alvaro Herrera writes: > >> Robert Haas wrote: > >>> So I think in the long run we should have three limits: > >>> >

Re: [HACKERS] Rename max_parallel_degree?

On Tue, May 31, 2016 at 1:27 PM, Alvaro Herrera wrote: > This is a very good point. > > I think parallel maintenance commands are going to require different > tuning than different queries, and I'd rather have separate parameters > for those things rather than force the

Re: [HACKERS] Rename max_parallel_degree?

Robert Haas wrote: > I just want to point out that if we change #1, we're breaking > postgresql.conf compatibility for, IMHO, not a whole lot of benefit. > I'd just leave it alone. We can add the old name as a synonym in guc.c to maintain compatibility. > I would propose to call #2

Re: [HACKERS] Rename max_parallel_degree?

On Tue, May 31, 2016 at 4:04 PM, Tom Lane wrote: > Alvaro Herrera writes: >> Robert Haas wrote: >>> So I think in the long run we should have three limits: >>> >>> 1. Cluster-wide limit on number of worker processes for all purposes >>> (currently,

  1   2   >