Re: Rename max_parallel_degree?

From: Josh berkus <josh(at)agliodbs(dot)com>
To: Peter Geoghegan <pg(at)heroku(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Rename max_parallel_degree?
Date: 2016-05-31 18:02:54
Message-ID: 574DD1CE.2000307@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 05/31/2016 10:51 AM, Peter Geoghegan wrote:
> On Tue, May 31, 2016 at 10:46 AM, Josh berkus <josh(at)agliodbs(dot)com> 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), it will start acting as a worker fairly quickly.
> With parallel aggregate, and some other cases, that will always happen.
>
> 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.
>

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.

--
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-05-31 18:04:40 Re: Rename synchronous_standby_names?
Previous Message Tom Lane 2016-05-31 18:00:25 Re: Rename max_parallel_degree?