On Mon, Apr 25, 2016 at 11:27 AM, Joshua D. Drake <jd@commandprompt.com> wrote:
> max_parallel_nodes
I hope you are trolling me. It does not bound the maximum number of
parallel nodes, but rather the maximum number of workers per parallel
node. In most cases, a query is only going to have one parallel node,
but sometimes it could have more than one. In all of the actual cases
tested by me thus far, the workers for one node terminate before we
try to launch workers for another node, but it is theoretically
possible to have a query plan where this isn't the case. It is
getting a bit irritating to me to people who seem not even to have
read the existing documentation for this GUC, let alone tried it out
and gotten familiar with what it does, are convinced they know how it
should be changed.
On the underlying issue, the max_parallel_degree naming is tied into
the parallel_degree reloption and the parallel_degree field that is
part of each Path. If you want to rename any of those, you are going
to need to rename them all, I think. So we could do
max_parallel_degree -> max_parallel_workers_per_executor_node and
parallel_degree -> target_number_of_parallel_workers, but that is
rather longwinded and it's very difficult to shorten those very much
without losing clarity. I grant that there is some learning curve in
getting familiar with new terms of art, like "parallel degree", but in
the long run it's better to ask people to learn a few new terms than
to trying to repeat the whole description of what the thing is every
time you refer to it. We've got existing terms of art like
"multixact" or even "wraparound" that are far, far more obscure than
this, and those are entirely PostgreSQL-specific things without a hint
of any parallel in other products.
The concept of parallel degree is not going away, and its reach
extends well beyond the GUC. We can rename it to some other term, but
this one is pretty standard. Trying to avoid having a term for it is
not going to work.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
