Re: Can we do something to help stop users mistakenly using force_parallel_mode?
От | Justin Pryzby |
---|---|
Тема | Re: Can we do something to help stop users mistakenly using force_parallel_mode? |
Дата | |
Msg-id | 20220629123101.GF28130@telsasoft.com обсуждение исходный текст |
Ответ на | Can we do something to help stop users mistakenly using force_parallel_mode? (David Rowley <dgrowleyml@gmail.com>) |
Ответы |
Re: Can we do something to help stop users mistakenly using force_parallel_mode?
Re: Can we do something to help stop users mistakenly using force_parallel_mode? |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: