On Wed, Jun 29, 2022 at 03:23:27PM +1200, David Rowley wrote: > Over on [1] I noticed that the user had set force_parallel_mode to > "on" in the hope that would trick the planner into making their query > run more quickly. Of course, that's not what they want since that GUC > is only there to inject some parallel nodes into the plan in order to > verify the tuple communication works. > > I get the idea that Robert might have copped some flak about this at > some point, given that he wrote the blog post at [2]. > > The user would have realised this if they'd read the documentation > about the GUC. However, I imagine they only went as far as finding a > GUC with a name which appears to be exactly what they need. I mean, > what else could force_parallel_mode possibly do?
Note that it was already changed to be a developer GUC https://www.postgresql.org/message-id/20210404012546.GK6592%40telsasoft.com And I asked if that re-classification should be backpatched: > It's to their benefit and ours if they don't do that on v10-13 for the next 5 > years, not just v14-17. Since the user in this recent thread is running v13.7, I'm *guessing* that if that had been backpatched, they wouldn't have made this mistake. > I wonder if \dconfig *parallel* is going to make force_parallel_mode > even easier to find once PG15 is out. Maybe. Another consequence is that if someone *does* set f_p_m, it may be a bit easier and more likely for a local admin to discover it (before mailing the pgsql lists). -- Justin
