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?
Red Hat OSAS
(any opinions are my own)
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: