On Wed, Jun 1, 2016 at 10:10 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Amit Kapila <amit.kapil...@gmail.com> writes: >> Your explanation is clear, however the name max_parallel_workers makes it >> sound like that parallelising an operation is all about workers. Yes it >> depends a lot on the number of workers allocated for parallel operation, >> but that is not everything. I think calling it max_parallelism as >> suggested by Alvaro upthread suits better than max_parallel_workers. > > I don't think that's a good direction at all. This entire discussion is > caused by the fact that it's not very clear what "max_parallel_degree" > measures. Fixing that problem by renaming the variable to something that > doesn't even pretend to tell you what it's counting is not an improvement.
I agree with that, but I also think you're holding the name of this GUC to a ridiculously high standard. It's not like you can look at "work_mem" and know what it measures without reading the fine manual. If you lined up ten people in a room all of whom were competent database professionals and none of whom knew anything about PostgreSQL and asked them to guess what a setting called work_mem does and what a setting called max_parallel_degree does, I will wager you $5 that they'd do better on the second one. Likewise, I bet the guesses for max_parallel_degree would be closer to the mark than the guesses for maintenance_work_mem or replacement_sort_tuples or commit_siblings or bgwriter_lru_multiplier. I've largely given up hope of coming up with an alternative that can attract more than one vote and that is also at least mildly accurate, but one idea is max_parallel_workers_per_gather_node. That will be totally clear. Three possible problems, none of them fatal, are: - I have plans to eventually fix it so that the workers are shared across the whole plan rather than just the plan node. In most cases that won't matter, but there are corner cases where it does. Now when that happens, we can rename this to max_parallel_workers_per_query, breaking backward compatibility. - It will force us to use a different GUC for utility commands. - It's a bit long-winded. -- 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