Pavlo Golub: New old “debug_parallel_query” setting in PostgreSQL 16

Naming variables Why will force_parallel_mode – the runtime option be renamed to debug_parallel_query in PostgreSQL 16? Proper variable and function naming play a vital role in making code understandable, maintainable, and easily shareable. When we give our variables descriptive names that reflect their purpose, it becomes much simpler for others to understand our code, follow our logic, and make necessary changes. Using vague or ambiguous variable names makes our code more challenging to read. People often tend to ignore manuals and rely solely on variable names to guess their purpose. However, this can lead to errors and misunderstandings, making it essential to take the time to name variables thoughtfully and accurately. That is exactly what happened to “force_parallel_mode” PostgreSQL runtime option. It led some users to think this parameter somehow enables parallel query execution, which is absolutely not the case! Rename it to debug_parallel_query! Immediately! Thanks to David Rowley, this setting will have a new name “debug_parallel_query”. The patch was reviewed by John Naylor. Committed by David Rowley. The commit message is: force_parallel_mode is meant to be used to allow us to exercise the parallel query infrastructure to ensure that it's working as we expect. It seems some users think this GUC is for forcing the query planner into picking a parallel plan regardless of the costs. A quick look at the documentation would have made them realize that they were wrong, but the GUC is likely too conveniently named which, evidently, seems to often result in users expecting that it forces the planner into usefully parallelizing queries. Here we rename the GUC to something which casual users are less likely to mistakenly think is what they need to make their query run more quickly. For now, the old name can still be used. We'll revisit if the old name mapping can be removed once the buildfarm configs are all updated. Reviewed-by: John Naylor Discussion: https://postgr.es/m/CAApHDvrsOi9[...]