On Sun, Apr 24, 2016 at 2:42 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Magnus Hagander <mag...@hagander.net> writes:
>> On Sun, Apr 24, 2016 at 8:23 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>>> FWIW, I agree with Bruce that using "degree" here is a poor choice.
>>> It's an unnecessary dependence on technical terminology that many people
>>> will not be familiar with.
>> FWIW, SQL Server calls it "degree of parallelism" as well (
>> https://technet.microsoft.com/en-us/library/ms188611(v=sql.105).aspx). And
>> their configuration option is "max degree of parallelism":
> Yes, but both they and Oracle appear to consider "degree" to mean the
> total number of processors used, not the number of secondary jobs in
> addition to the main one. The only thing worse than employing obscure
> technical terminology is employing it incorrectly: that way, you get to
> confuse both the users who know what it means and those who don't.
This is not so clear-cut as you are making it out to be. For example,
see http://www.akadia.com/services/ora_parallel_processing.html - viz
"The number of parallel slave processes associated with an operation
is called its degree of parallelism", which is pretty close to what
the parameter currently called max_parallel_degree actually does.
- "The Degree of Parallelism (DOP) defines the number of parallel
streams of execution that will be created. In the simplest case, this
translates to the number of parallel slave processes enlisted to
support your SQL's execution. However, the number of parallel
processes is more often twice the DOP. This is because each step in a
nontrivial execution plan needs to feed data into the subsequent step,
so two sets of processes are required to maintain the parallel stream
Other sources disagree, of course, as is often the case with Oracle. Wahoo.
Of course, we could make this value 1-based rather than 0-based, as
Peter Geoghegan suggested a while back. But as I think I said at the
time, I think that's more misleading than helpful. The leader
participates in the parallel plan, but typically does far less of the
work beneath the Gather node than the other nodes involved in the
query, often almost none. In short, the leader is special.
Pretending that it's just another process involved in the parallel
group isn't doing anyone a favor.
The Enterprise PostgreSQL Company
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: