On 05/31/2016 10:38 AM, Peter Geoghegan wrote: > On Tue, May 31, 2016 at 10:23 AM, Josh berkus <j...@agliodbs.com> 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-worker when executing a parallel query, then > you have another consideration. Which is that you need to care about > how many cores your query uses first and foremost, and not the number > of parallel workers used. I don't think that having only one worker > will cause too much confusion, because users will trust that we won't > allow something that simply makes no sense to happen. > > In my parallel create index patch, the leader participates as a worker > to scan and sort runs. It's identical to a worker, practically > speaking, at least until time comes to merge those runs. Similarly, > parallel aggregate does not really have much for the leader process to > do other than act as a worker.
In parallel seq scan and join, do the "masters" behave as workers as well? -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
