From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Josh berkus <josh(at)agliodbs(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 17:51:28 |
Message-ID: | CAM3SWZQTmjE+O-NnGthzLd61RtXkNfitWrZU6zJHHHZSB3YmEg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-05-31 18:00:25 | Re: Rename max_parallel_degree? |
Previous Message | Jaime Casanova | 2016-05-31 17:47:23 | Rename synchronous_standby_names? |