Re: [HACKERS] ExecGather() + nworkers

2016-03-07 Thread Robert Haas
On Mon, Mar 7, 2016 at 2:13 PM, Peter Geoghegan wrote: > On Mon, Mar 7, 2016 at 4:04 AM, Amit Kapila wrote: >> Your point is genuine, but OTOH let us say if max_parallel_degree = 1 means >> parallelism is disabled then when somebody sets

Re: [HACKERS] ExecGather() + nworkers

2016-03-07 Thread Peter Geoghegan
On Mon, Mar 7, 2016 at 4:04 AM, Amit Kapila wrote: > Your point is genuine, but OTOH let us say if max_parallel_degree = 1 means > parallelism is disabled then when somebody sets max_parallel_degree = 2, > then it looks somewhat odd to me that, it will mean that 1 worker

Re: [HACKERS] ExecGather() + nworkers

2016-03-07 Thread Amit Kapila
On Mon, Jan 11, 2016 at 3:14 AM, Peter Geoghegan wrote: > > On Sun, Jan 10, 2016 at 9:13 AM, Robert Haas wrote: > > Now, you might wonder why it is that the leader cannot also sort runs, > just as a worker would. It's possible, but it isn't exactly >

Re: [HACKERS] ExecGather() + nworkers

2016-03-04 Thread Amit Kapila
On Fri, Mar 4, 2016 at 11:41 PM, Robert Haas wrote: > On Fri, Mar 4, 2016 at 6:55 AM, Amit Kapila > wrote: > > On Fri, Mar 4, 2016 at 5:21 PM, Haribabu Kommi > > > wrote: > >> > >> On Fri, Mar 4, 2016 at 10:33 PM, Amit

Re: [HACKERS] ExecGather() + nworkers

2016-03-04 Thread Robert Haas
On Fri, Mar 4, 2016 at 6:55 AM, Amit Kapila wrote: > On Fri, Mar 4, 2016 at 5:21 PM, Haribabu Kommi > wrote: >> >> On Fri, Mar 4, 2016 at 10:33 PM, Amit Kapila >> wrote: >> > On Fri, Mar 4, 2016 at 11:57 AM, Haribabu

Re: [HACKERS] ExecGather() + nworkers

2016-03-04 Thread Amit Kapila
On Fri, Mar 4, 2016 at 5:21 PM, Haribabu Kommi wrote: > On Fri, Mar 4, 2016 at 10:33 PM, Amit Kapila > wrote: > > On Fri, Mar 4, 2016 at 11:57 AM, Haribabu Kommi < > kommi.harib...@gmail.com> > > wrote: > >> > >> On Wed, Jan 13, 2016 at 7:19

Re: [HACKERS] ExecGather() + nworkers

2016-03-04 Thread Haribabu Kommi
On Fri, Mar 4, 2016 at 10:33 PM, Amit Kapila wrote: > On Fri, Mar 4, 2016 at 11:57 AM, Haribabu Kommi > wrote: >> >> On Wed, Jan 13, 2016 at 7:19 PM, Amit Kapila >> wrote: >> >> >> > >> > Changed the code such that

Re: [HACKERS] ExecGather() + nworkers

2016-03-04 Thread Amit Kapila
On Fri, Mar 4, 2016 at 11:57 AM, Haribabu Kommi wrote: > On Wed, Jan 13, 2016 at 7:19 PM, Amit Kapila > wrote: > >> > > > > Changed the code such that nworkers_launched gets used wherever > > appropriate instead of nworkers. This includes

Re: [HACKERS] ExecGather() + nworkers

2016-03-03 Thread Haribabu Kommi
On Wed, Jan 13, 2016 at 7:19 PM, Amit Kapila wrote: > On Mon, Jan 11, 2016 at 9:16 AM, Amit Kapila > wrote: >> On Mon, Jan 11, 2016 at 3:14 AM, Peter Geoghegan wrote: >> > >> > On Sun, Jan 10, 2016 at 9:13 AM, Robert Haas

Re: [HACKERS] ExecGather() + nworkers

2016-01-13 Thread Amit Kapila
On Mon, Jan 11, 2016 at 9:16 AM, Amit Kapila wrote: > On Mon, Jan 11, 2016 at 3:14 AM, Peter Geoghegan wrote: > > > > On Sun, Jan 10, 2016 at 9:13 AM, Robert Haas wrote: > > >> I'm not sure why the test for nworkers following the

Re: [HACKERS] ExecGather() + nworkers

2016-01-11 Thread Peter Geoghegan
On Sun, Jan 10, 2016 at 5:45 PM, Robert Haas wrote: > Well, in general, the parallel sort code doesn't really get to pick > whether or not a BackgroundWorkerSlot gets used or not. Whoever > created the parallel context decides how many workers to request, and > then the

Re: [HACKERS] ExecGather() + nworkers

2016-01-10 Thread Robert Haas
On Sun, Jan 10, 2016 at 4:44 PM, Peter Geoghegan wrote: >> I don't really understand why this should be so. I thought the idea >> of parallel sort is (roughly) that each worker should read data until >> it fills work_mem, sort that data, and write a tape. Repeat until no >>

Re: [HACKERS] ExecGather() + nworkers

2016-01-10 Thread Amit Kapila
On Mon, Jan 11, 2016 at 3:14 AM, Peter Geoghegan wrote: > > On Sun, Jan 10, 2016 at 9:13 AM, Robert Haas wrote: > >> I'm not sure why the test for nworkers following the > >> LaunchParallelWorkers() call doesn't look like this, though: > >> > >> /* Set

Re: [HACKERS] ExecGather() + nworkers

2016-01-10 Thread Pavel Stehule
> > > More importantly, I have other, entirely general concerns. Other major > > RDBMSs have settings that are very similar to max_parallel_degree, > > with a setting of 1 effectively disabling all parallelism. Both Oracle > > and SQL Server have settings that they both call the "maximum degree >

Re: [HACKERS] ExecGather() + nworkers

2016-01-10 Thread Robert Haas
On Sun, Jan 10, 2016 at 12:29 AM, Peter Geoghegan wrote: > The Gather node executor function ExecGather() does this: > [ code ] > I'm not sure why the test for nworkers following the > LaunchParallelWorkers() call doesn't look like this, though: > > /* Set up tuple queue

Re: [HACKERS] ExecGather() + nworkers

2016-01-10 Thread Peter Geoghegan
On Sun, Jan 10, 2016 at 9:13 AM, Robert Haas wrote: >> I'm not sure why the test for nworkers following the >> LaunchParallelWorkers() call doesn't look like this, though: >> >> /* Set up tuple queue readers to read the results. */ >> if (pcxt->nworkers_launched >

Re: [HACKERS] ExecGather() + nworkers

2016-01-10 Thread Peter Geoghegan
On Sun, Jan 10, 2016 at 1:44 PM, Peter Geoghegan wrote: > With parallel sequential scan, a max_parallel_degree of 8 could result > in 16 processes scanning in parallel. I meant a max_worker_processes setting, which of course is different. Nevertheless, I find it surprising that

[HACKERS] ExecGather() + nworkers

2016-01-09 Thread Peter Geoghegan
The Gather node executor function ExecGather() does this: /* * Register backend workers. We might not get as many as we * requested, or indeed any at all. */ pcxt = node->pei->pcxt; LaunchParallelWorkers(pcxt); /* Set up tuple queue readers to read the results. */