On Mon, Apr 25, 2016 at 11:27 AM, Joshua D. Drake <j...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
