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.

Table of Contents

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/CAApHDvrsOi92_uA7PEaHZMH-S4Xv+MGhQWA+GrP8b1kjpS1HjQ@mail.gmail.com

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

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/CAApHDvrsOi92_uA7PEaHZMH-S4Xv+MGhQWA+GrP8b1kjpS1HjQ@mail.gmail.com

What can I say? Sounds legit to me! I'll never-ever touch a runtime option with a "debug" prefix on my production clusters. What about you? 😉

Finally

If you want to know more about available PostgreSQL runtime options aka GUCs (Grand Unified Configuration) check the official manual.

And, of course, check out out the “what’s new” post series to know more about upcoming PostgreSQL versions.

In order to receive regular updates on important changes in PostgreSQL, subscribe to our newsletter, or follow us on Twitter, Facebook, or LinkedIn.

Comments are closed.