Re: Can we do something to help stop users mistakenly using force_parallel_mode? - Mailing list pgsql-hackers

From David Rowley
Subject Re: Can we do something to help stop users mistakenly using force_parallel_mode?
Date
Msg-id CAApHDvoH84+-CxJ0fXUHm70-QoRuoFwMJJGjsZQ_5-HKicD9dA@mail.gmail.com
Whole thread Raw
In response to Re: Can we do something to help stop users mistakenly using force_parallel_mode?  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: Can we do something to help stop users mistakenly using force_parallel_mode?
List pgsql-hackers
On Thu, 30 Jun 2022 at 00:31, Justin Pryzby <pryzby@telsasoft.com> wrote:
>
> 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.

> Note that it was already changed to be a developer GUC
> https://www.postgresql.org/message-id/20210404012546.GK6592%40telsasoft.com

> 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 was just reading [1] where a PG15 user made this mistake, so it
seems people are still falling for it even now it's been changed to a
developer GUC.

I don't really share Laurenz's worry [2] about compatibility break
from renaming this GUC. I think the legitimate usages of this setting
are probably far more rare than the illegitimate ones. I'm not overly
concerned about renaming if it helps stop people from making this
mistake. I believe the current name is just too conveniently named and
that users are likely just to incorrectly assume it does exactly what
they want because what else could it possibly do?!

I think something like debug_parallel_query is much less likely to be misused.

David

[1] https://www.postgresql.org/message-id/CAN4ko3B4y75pg5Ro_oAjWf8L1HYSYgXcDgsS6nzOTvQOkKnM1Q@mail.gmail.com
[2] https://www.postgresql.org/message-id/26139c03e118bec967c77da374d947e9ecf81333.camel@cybertec.at



pgsql-hackers by date:

Previous
From: Melih Mutlu
Date:
Subject: Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication
Next
From: Melih Mutlu
Date:
Subject: Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication