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