On 05/31/2016 01: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?
How about parallel_worker_pool?
--
--
Josh Berkus
Red Hat OSAS
(any opin
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, max_worker_processes).
>>
>> 2. Cluster-wide limit on number of worker processes for parallelism
>> (do
On Tue, May 31, 2016 at 12:55 PM, Alvaro Herrera
wrote:
> Agreed -- things like pglogical and BDR rely on background workers to do
> their jobs. Many other users of bgworkers have popped up, so I think
> it'd be a bad idea if parallel queries are able to monopolize all the
> available slots.
Tha
Robert Haas wrote:
> Also, I think that we might actually want to add an
> additional GUC to prevent the parallel query system from consuming the
> entire pool of processes established by max_worker_processes. If
> you're doing anything else with worker processes on your system, you
> might well
On Tue, May 31, 2016 at 3:35 PM, Robert Haas wrote:
> On Tue, May 31, 2016 at 3:19 PM, Tom Lane wrote:
> > I wrote:
> >> At the risk of opening another can of worms, what about renaming
> >> max_worker_processes as well? It would be a good thing if that
> >> had "cluster" in it somewhere, or so
On Tue, May 31, 2016 at 3:19 PM, Tom Lane wrote:
> I wrote:
> > At the risk of opening another can of worms, what about renaming
> > max_worker_processes as well? It would be a good thing if that
> > had "cluster" in it somewhere, or something that indicates it's a
> > system-wide value not a pe
On Tue, May 31, 2016 at 3:19 PM, Tom Lane wrote:
> I wrote:
>> At the risk of opening another can of worms, what about renaming
>> max_worker_processes as well? It would be a good thing if that
>> had "cluster" in it somewhere, or something that indicates it's a
>> system-wide value not a per-ses
I wrote:
> At the risk of opening another can of worms, what about renaming
> max_worker_processes as well? It would be a good thing if that
> had "cluster" in it somewhere, or something that indicates it's a
> system-wide value not a per-session value. "max_workers_per_cluster"
> would answer, t
On Tue, May 31, 2016 at 2:37 PM, Josh berkus wrote:
> On 05/31/2016 11:27 AM, Peter Geoghegan wrote:
> > On Tue, May 31, 2016 at 11:22 AM, Josh berkus wrote:
> >>> I think we can hope that developers are going to be less confused about
> >>> that than users.
> >>
> >> Makes sense.
> >
> > Maybe
Josh berkus writes:
> On 05/31/2016 11:29 AM, Tom Lane wrote:
>> Josh berkus writes:
>>> One more consistency question: what's the effect of running out of
>>> max_parallel_workers?
>> ITYM max_worker_processes (ie, the cluster-wide pool size)?
> Yes. Sorry for contributing to the confusion.
On 05/31/2016 11:29 AM, Tom Lane wrote:
> Josh berkus writes:
>> One more consistency question: what's the effect of running out of
>> max_parallel_workers?
>
> ITYM max_worker_processes (ie, the cluster-wide pool size)?
Yes. Sorry for contributing to the confusion. Too many
similar-sounding p
On 05/31/2016 11:27 AM, Peter Geoghegan wrote:
> On Tue, May 31, 2016 at 11:22 AM, Josh berkus wrote:
>>> I think we can hope that developers are going to be less confused about
>>> that than users.
>>
>> Makes sense.
>
> Maybe EXPLAIN doesn't have to use the term parallel worker at all. It
> can
Josh berkus writes:
> One more consistency question: what's the effect of running out of
> max_parallel_workers?
ITYM max_worker_processes (ie, the cluster-wide pool size)?
> 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
On Tue, May 31, 2016 at 2:22 PM, Josh berkus wrote:
> 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 eith
On Tue, May 31, 2016 at 11:22 AM, Josh berkus wrote:
>> I think we can hope that developers are going to be less confused about
>> that than users.
>
> Makes sense.
Maybe EXPLAIN doesn't have to use the term parallel worker at all. It
can instead use a slightly broader terminology, possibly inclu
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 ourse
"David G. Johnston" writes:
> On Tuesday, May 31, 2016, Tom Lane 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.
> What is your opinion on the internal name for this? Leave it as "degree"?
On Tue, May 31, 2016 at 11:17 AM, Peter Eisentraut
wrote:
> 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
"David G. Johnston" writes:
> On Tuesday, May 31, 2016, Tom Lane 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.
> If going this route I'd still rather add the word "assisting"
> or "addit
On Tuesday, May 31, 2016, Peter Geoghegan wrote:
> On Tue, May 31, 2016 at 11:02 AM, 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
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 expla
On Tuesday, May 31, 2016, 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 documentation patch
> with Robert's. Whic
On Tue, May 31, 2016 at 11:09 AM, Peter Geoghegan wrote:
> The only reason I favor defining parallel_degree = 1
I meant "redefining max_parallel_degree =1 to effectively disable
parallel query", of course.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
On Tue, May 31, 2016 at 11:02 AM, 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.
Peter Geoghegan writes:
> Even when the leader is consuming input from workers, that's still perhaps
> pegging one CPU core. So, it doesn't really invalidate what I said about
> the number of cores being the primary consideration.
Agreed, but if we think that people need to be thinking in those t
On Tuesday, May 31, 2016, Tom Lane wrote:
> Josh berkus > writes:
> > On 05/31/2016 10:16 AM, Peter Geoghegan wrote:
> >> But the distinction between parallel workers and backends that can
> >> participate in parallel query does need to be user-visible. Worker
> >> processes are a commodity (i.e.
On 05/31/2016 10:51 AM, Peter Geoghegan wrote:
> On Tue, May 31, 2016 at 10:46 AM, Josh berkus wrote:
>> In parallel seq scan and join, do the "masters" behave as workers as well?
>
> It depends. They will if they can. If the parallel seq scan leader
> isn't getting enough work to do from workers
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 documentation patch
with Robert's. Which one is more understandable?
(I have not bothered pre
On Tue, May 31, 2016 at 10:46 AM, Josh berkus wrote:
> In parallel seq scan and join, do the "masters" behave as workers as well?
It depends. They will if they can. If the parallel seq scan leader
isn't getting enough work to do from workers (enough tuples to process
from the shared memory queue)
On 05/31/2016 10:38 AM, Peter Geoghegan wrote:
> On Tue, May 31, 2016 at 10:23 AM, Josh berkus wrote:
>> It's still WAY simpler to understand "max_parallel is the number of
>> parallel workers I requested".
>
> (Sorry Josh, somehow hit reply, not reply-all)
>
> Yes, it is. But as long as paralle
On 05/31/2016 10:30 AM, Tom Lane wrote:
Josh berkus writes:
On 05/31/2016 10:16 AM, Peter Geoghegan wrote:
But the distinction between parallel workers and backends that can
participate in parallel query does need to be user-visible. Worker
processes are a commodity (i.e. the user must conside
On Tue, May 31, 2016 at 10:23 AM, Josh berkus wrote:
> It's still WAY simpler to understand "max_parallel is the number of
> parallel workers I requested".
(Sorry Josh, somehow hit reply, not reply-all)
Yes, it is. But as long as parallel workers are not really that
distinct to the leader-as-wor
Josh berkus writes:
> On 05/31/2016 10:16 AM, Peter Geoghegan wrote:
>> But the distinction between parallel workers and backends that can
>> participate in parallel query does need to be user-visible. Worker
>> processes are a commodity (i.e. the user must consider
>> max_worker_processes).
> It
On 05/31/2016 10:16 AM, Peter Geoghegan wrote:
> On Tue, May 31, 2016 at 10:10 AM, Josh berkus wrote:
>> "max_parallel_degree is the amount of parallelism in the query, with the
>> understanding that the original parent process counts as 1, which means
>> that if you set it to 1 you get no paralle
On Tue, May 31, 2016 at 10:10 AM, Josh berkus wrote:
> "max_parallel_degree is the amount of parallelism in the query, with the
> understanding that the original parent process counts as 1, which means
> that if you set it to 1 you get no parallelism, and if you want 4
> parallel workers you need
On 05/31/2016 10:10 AM, Josh berkus wrote:
Compare this:
"max_parallel is the maximum number of parallel workers which will work
on each stage of the query which is parallizable. If you set it to 4,
you get up to 4 workers."
with this:
"max_parallel_degree is the amount of parallelism in the
On 05/31/2016 10:03 AM, Tom Lane wrote:
> Josh berkus writes:
>> I realize there's a lot of water under the bridge here, but I think
>> we're going to get 1000 questions on -general of the type: "I asked for
>> 8 parallel workers, why did I only get 7?". I believe we will regret
>> this change.
Josh berkus writes:
> I realize there's a lot of water under the bridge here, but I think
> we're going to get 1000 questions on -general of the type: "I asked for
> 8 parallel workers, why did I only get 7?". I believe we will regret
> this change.
> So, one vote from me to revert.
Well, that
On 05/31/2016 09:15 AM, Robert Haas wrote:
> On Sun, May 29, 2016 at 1:33 AM, Noah Misch wrote:
>> On Fri, May 06, 2016 at 02:52:30PM -0400, Robert Haas wrote:
>>> OK, my reading of this thread is that there is a consensus is to
>>> redefine max_parallel_degree=1 as "no parallelism" and
>>> max_pa
On Sun, May 29, 2016 at 1:33 AM, Noah Misch wrote:
> On Fri, May 06, 2016 at 02:52:30PM -0400, Robert Haas wrote:
>> OK, my reading of this thread is that there is a consensus is to
>> redefine max_parallel_degree=1 as "no parallelism" and
>> max_parallel_degree>1 as "parallelism using a leader pl
On Fri, May 06, 2016 at 02:52:30PM -0400, Robert Haas wrote:
> OK, my reading of this thread is that there is a consensus is to
> redefine max_parallel_degree=1 as "no parallelism" and
> max_parallel_degree>1 as "parallelism using a leader plus N-1
> workers", and along with that, to keep the names
On Tue, May 3, 2016 at 11:42 PM, David Rowley
wrote:
>>> Magnus seems OK with the way things are.
>>> Peter wants to change either the fact that it is 0-based or the fact
>>> that it is called degree, but is OK with either.
>>> Tom doesn't like "degree" and also thinks anything called degree
>>> s
On 4 May 2016 at 15:12, Amit Kapila wrote:
> On Mon, May 2, 2016 at 11:47 PM, Robert Haas wrote:
>>
>> On Tue, Apr 26, 2016 at 11:49 AM, Robert Haas
>> wrote:
>> > On Tue, Apr 26, 2016 at 11:44 AM, Tom Lane wrote:
>> >> Robert Haas writes:
>>
>> To summarize the positions as I understand them:
On Mon, May 2, 2016 at 11:47 PM, Robert Haas wrote:
>
> On Tue, Apr 26, 2016 at 11:49 AM, Robert Haas
wrote:
> > On Tue, Apr 26, 2016 at 11:44 AM, Tom Lane wrote:
> >> Robert Haas writes:
>
> To summarize the positions as I understand them:
>
> Magnus seems OK with the way things are.
> Peter w
On Mon, May 2, 2016 at 12:14 PM, Robert Haas wrote:
> On Mon, May 2, 2016 at 2:44 PM, David G. Johnston
> wrote:
> > Does this apply to the extent that a value of 1 is likely worse than 0
> since
> > the leader is now tasked with accumulating but there is only one process
> > actually working to
On Mon, May 2, 2016 at 3:18 PM, Christoph Berg wrote:
> Re: Robert Haas 2016-05-02
>
>> max_parallel_degree -> max_parallel_workers
>> parallel_degree -> parallel_workers
>>
>> I would prefer to keep it as "degree". It's a reasonable term of art,
>> and it also improves grep-ability. But I'm w
Re: Robert Haas 2016-05-02
> max_parallel_degree -> max_parallel_workers
> parallel_degree -> parallel_workers
>
> I would prefer to keep it as "degree". It's a reasonable term of art,
> and it also improves grep-ability. But I'm willing to go do the above
> renaming if there is a clear consen
On Mon, May 2, 2016 at 2:44 PM, David G. Johnston
wrote:
> Does this apply to the extent that a value of 1 is likely worse than 0 since
> the leader is now tasked with accumulating but there is only one process
> actually working to provide the leader data?
I don't know what that means, but it do
On Sun, Apr 24, 2016 at 8:01 PM, Robert Haas wrote:
>
> Of course, we could make this value 1-based rather than 0-based, as
> Peter Geoghegan suggested a while back. But as I think I said at the
> time, I think that's more misleading than helpful. The leader
> participates in the parallel plan,
On Tue, Apr 26, 2016 at 11:49 AM, Robert Haas wrote:
> On Tue, Apr 26, 2016 at 11:44 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> I still think
>>> max_parallel_workers is confusingly similar to max_worker_processes,
>>> but nothing's going to make everyone completely happy here.
>>
>> Well, w
On Sat, Apr 30, 2016 at 4:54 AM, David Rowley
wrote:
>> Right, but they're probably not doing the SAME work. You can look at
>> EXPLAIN (ANALYZE, VERBOSE, BUFFERS) to see. Of course, all the work
>> above the Gather node is being done by the leader, but the stuff below
>> the Gather node often h
On 29 April 2016 at 02:41, Robert Haas wrote:
> On Wed, Apr 27, 2016 at 1:05 PM, Daniel Verite
> wrote:
>> Robert Haas wrote:
>>> Of course, we could make this value 1-based rather than 0-based, as
>>> Peter Geoghegan suggested a while back. But as I think I said at the
>>> time, I thin
On Wed, Apr 27, 2016 at 1:05 PM, Daniel Verite wrote:
> Robert Haas wrote:
>> Of course, we could make this value 1-based rather than 0-based, as
>> Peter Geoghegan suggested a while back. But as I think I said at the
>> time, I think that's more misleading than helpful. The leader
>> pa
Robert Haas wrote:
> Of course, we could make this value 1-based rather than 0-based, as
> Peter Geoghegan suggested a while back. But as I think I said at the
> time, I think that's more misleading than helpful. The leader
> participates in the parallel plan, but typically does far less
On Tue, Apr 26, 2016 at 11:44 AM, Tom Lane wrote:
> Robert Haas writes:
>> I still think
>> max_parallel_workers is confusingly similar to max_worker_processes,
>> but nothing's going to make everyone completely happy here.
>
> Well, what was suggested upthread was to change all of these to follo
Robert Haas writes:
> I still think
> max_parallel_workers is confusingly similar to max_worker_processes,
> but nothing's going to make everyone completely happy here.
Well, what was suggested upthread was to change all of these to follow
the pattern max_foo_workers or max_foo_worker_processes,
On Tue, Apr 26, 2016 at 11:34 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Apr 26, 2016 at 11:22 AM, Alvaro Herrera
>> wrote:
>>> I think the word "degree" is largely seen as a bad idea: it would become
>>> a somewhat better idea only if we change how it works so that it matches
>>> what
Robert Haas writes:
> On Tue, Apr 26, 2016 at 11:22 AM, Alvaro Herrera
> wrote:
>> I think the word "degree" is largely seen as a bad idea: it would become
>> a somewhat better idea only if we change how it works so that it matches
>> what other DBMSs do, but you oppose that. Hence my proposal t
On Tue, Apr 26, 2016 at 11:22 AM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> On Mon, Apr 25, 2016 at 2:58 PM, Alvaro Herrera
>> wrote:
>
>> > What about calling it something even simpler, such as "max_parallelism"?
>> > This avoids such cargo cult, and there's no implication that it's
>> > per
Robert Haas wrote:
> On Mon, Apr 25, 2016 at 2:58 PM, Alvaro Herrera
> wrote:
> > What about calling it something even simpler, such as "max_parallelism"?
> > This avoids such cargo cult, and there's no implication that it's
> > per-query.
>
> So what would we call the "parallel_degree" member o
On Mon, Apr 25, 2016 at 1:45 PM, Robert Haas wrote:
>> I think the "degree" terminology is fundamentally tainted by the question
>> of whether or not it counts the leader, and that we will have bugs (or
>> indeed may have them today) caused by getting that wrong.
>
> This theory does not seem very
On Mon, Apr 25, 2016 at 4:24 PM, Tom Lane wrote:
> Robert Haas writes:
>>> What about calling it something even simpler, such as "max_parallelism"?
>>> This avoids such cargo cult, and there's no implication that it's
>>> per-query.
>
>> So what would we call the "parallel_degree" member of the P
On Mon, Apr 25, 2016 at 1:24 PM, Tom Lane wrote:
> I think we should rename all of these to something based on the concept of
> "number of worker processes", and adjust the code if necessary to match.
> I think the "degree" terminology is fundamentally tainted by the question
> of whether or not i
Robert Haas writes:
>> What about calling it something even simpler, such as "max_parallelism"?
>> This avoids such cargo cult, and there's no implication that it's
>> per-query.
> So what would we call the "parallel_degree" member of the Path data
> structure, and the "parallel_degree" reloption
On 26/04/16 06:38, Joshua D. Drake wrote:
On 04/25/2016 09:04 AM, Robert Haas wrote:
On Mon, Apr 25, 2016 at 11:27 AM, Joshua D. Drake
wrote:
max_parallel_nodes
I hope you are trolling me.
Actually I wasn't. It is usually a little more obvious when I troll,
subtlety is not exactly my stro
On Mon, Apr 25, 2016 at 2:58 PM, Alvaro Herrera
wrote:
> Tom Lane wrote:
>> Magnus Hagander writes:
>> > On Sun, Apr 24, 2016 at 8:23 PM, Tom Lane wrote:
>> >> FWIW, I agree with Bruce that using "degree" here is a poor choice.
>> >> It's an unnecessary dependence on technical terminology that m
Tom Lane wrote:
> Magnus Hagander writes:
> > On Sun, Apr 24, 2016 at 8:23 PM, Tom Lane wrote:
> >> FWIW, I agree with Bruce that using "degree" here is a poor choice.
> >> It's an unnecessary dependence on technical terminology that many people
> >> will not be familiar with.
>
> > FWIW, SQL Se
On 04/25/2016 09:04 AM, Robert Haas wrote:
On Mon, Apr 25, 2016 at 11:27 AM, Joshua D. Drake
wrote:
max_parallel_nodes
I hope you are trolling me.
Actually I wasn't. It is usually a little more obvious when I troll,
subtlety is not exactly my strong suit ;)
The only reason I suggested t
On Mon, Apr 25, 2016 at 11:27 AM, Joshua D. Drake
wrote:
> max_parallel_nodes
I hope you are trolling me. It does not bound the maximum number of
parallel nodes, but rather the maximum number of workers per parallel
node. In most cases, a query is only going to have one parallel node,
but some
On 04/25/2016 07:08 AM, Bruce Momjian wrote:
On Sun, Apr 24, 2016 at 11:21:01AM +0530, Amit Kapila wrote:
On Sun, Apr 24, 2016 at 9:28 AM, Bruce Momjian wrote:
Why is the parallelism variable called "max_parallel_degree"? Is that a
descriptive name? What does "degree" mean?
It is to denot
On Sun, Apr 24, 2016 at 11:21:01AM +0530, Amit Kapila wrote:
> On Sun, Apr 24, 2016 at 9:28 AM, Bruce Momjian wrote:
> >
> > Why is the parallelism variable called "max_parallel_degree"? Is that a
> > descriptive name? What does "degree" mean?
>
> It is to denote amount of parallelism at node l
On Mon, Apr 25, 2016 at 12:17:56PM +0200, Magnus Hagander wrote:
>
>
> On Mon, Apr 25, 2016 at 5:01 AM, Robert Haas wrote:
>
> On Sun, Apr 24, 2016 at 2:42 PM, Tom Lane wrote:
> > Magnus Hagander writes:
> >> On Sun, Apr 24, 2016 at 8:23 PM, Tom Lane wrote:
> >>> FWIW, I agre
On 25 April 2016 at 03:44, Robert Haas wrote:
> On Sun, Apr 24, 2016 at 2:23 PM, Tom Lane wrote:
>> FWIW, I agree with Bruce that using "degree" here is a poor choice.
>> It's an unnecessary dependence on technical terminology that many people
>> will not be familiar with.
>
> And many others wil
On Mon, Apr 25, 2016 at 5:01 AM, Robert Haas wrote:
> On Sun, Apr 24, 2016 at 2:42 PM, Tom Lane wrote:
> > Magnus Hagander writes:
> >> On Sun, Apr 24, 2016 at 8:23 PM, Tom Lane wrote:
> >>> FWIW, I agree with Bruce that using "degree" here is a poor choice.
> >>> It's an unnecessary dependenc
On Sun, Apr 24, 2016 at 2:42 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Sun, Apr 24, 2016 at 8:23 PM, Tom Lane wrote:
>>> FWIW, I agree with Bruce that using "degree" here is a poor choice.
>>> It's an unnecessary dependence on technical terminology that many people
>>> will not be fami
On Sun, Apr 24, 2016 at 2:23 PM, Tom Lane wrote:
> FWIW, I agree with Bruce that using "degree" here is a poor choice.
> It's an unnecessary dependence on technical terminology that many people
> will not be familiar with.
And many others will. Some made-up term that is entirely
PostgreSQL-speci
On Sun, Apr 24, 2016 at 02:23:43PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > Also, consider that we have the related but actually sorta different
> > GUC max_worker_processes. I think max_parallel_workers to control the
> > per-query behavior and max_worker_processes to control the global
Magnus Hagander writes:
> On Sun, Apr 24, 2016 at 8:23 PM, Tom Lane wrote:
>> FWIW, I agree with Bruce that using "degree" here is a poor choice.
>> It's an unnecessary dependence on technical terminology that many people
>> will not be familiar with.
> FWIW, SQL Server calls it "degree of paral
On Sun, Apr 24, 2016 at 8:23 PM, Tom Lane wrote:
> Robert Haas writes:
> > On Sat, Apr 23, 2016 at 11:58 PM, Bruce Momjian
> wrote:
> >> Why is the parallelism variable called "max_parallel_degree"? Is that a
> >> descriptive name? What does "degree" mean? Why is it not called
> >> "max_para
Robert Haas writes:
> On Sat, Apr 23, 2016 at 11:58 PM, Bruce Momjian wrote:
>> Why is the parallelism variable called "max_parallel_degree"? Is that a
>> descriptive name? What does "degree" mean? Why is it not called
>> "max_parallel_workers"?
> Because "degree of parallelism" is standard t
On Sat, Apr 23, 2016 at 11:58 PM, Bruce Momjian wrote:
> Why is the parallelism variable called "max_parallel_degree"? Is that a
> descriptive name? What does "degree" mean? Why is it not called
> "max_parallel_workers"?
Because "degree of parallelism" is standard terminology, I guess.
Also,
On 04/23/2016 11:00 PM, Peter Geoghegan wrote:
On Sat, Apr 23, 2016 at 8:58 PM, Bruce Momjian wrote:
Why is the parallelism variable called "max_parallel_degree"? Is that a
descriptive name? What does "degree" mean? Why is it not called
"max_parallel_workers"?
I also think that "max_parall
On Sat, Apr 23, 2016 at 8:58 PM, Bruce Momjian wrote:
> Why is the parallelism variable called "max_parallel_degree"? Is that a
> descriptive name? What does "degree" mean? Why is it not called
> "max_parallel_workers"?
I also think that "max_parallel_workers" works better.
While certain othe
On Sun, Apr 24, 2016 at 9:28 AM, Bruce Momjian wrote:
>
> Why is the parallelism variable called "max_parallel_degree"? Is that a
> descriptive name? What does "degree" mean?
It is to denote amount of parallelism at node level.
>
> Why is it not called
> "max_parallel_workers"?
>
Degree of
Why is the parallelism variable called "max_parallel_degree"? Is that a
descriptive name? What does "degree" mean? Why is it not called
"max_parallel_workers"?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so onc
101 - 185 of 185 matches
Mail list logo
