On Wed, 12 Apr 2023 at 09:53, Tom Lane wrote:
> I don't see a reason to wait longer once the buildfarm is on board.
I did a final sweep of the latest runs for each animal this morning.
Everything has been switched over to debug_parallel_query, so I've
gone and pushed the patch to remove the
On Wed, 12 Apr 2023 at 09:53, Tom Lane wrote:
>
> David Rowley writes:
> > In preparation for when that's ticked off, I'd like to gather people's
> > thoughts about if we should remove force_parallel_mode from v16?
>
> To clarify, you just mean removing that alias, right? +1.
> I don't see a
David Rowley writes:
> In preparation for when that's ticked off, I'd like to gather people's
> thoughts about if we should remove force_parallel_mode from v16?
To clarify, you just mean removing that alias, right? +1.
I don't see a reason to wait longer once the buildfarm is on board.
On Thu, 16 Feb 2023 at 00:05, David Rowley wrote:
> I pushed the rename patch earlier.
>
> How should we go about making contact with the owners?
After a quick round of making direct contact with the few remaining
buildfarm machine owners which are still using force_parallel_mode,
we're now down
On 2023-02-15 We 06:05, David Rowley wrote:
On Wed, 15 Feb 2023 at 14:10, Andrew Dunstan wrote:
We'll email them once this is in. Most people are fairly reponsive.
I pushed the rename patch earlier.
How should we go about making contact with the owners? I'm thinking
it may be better coming
On Wed, 15 Feb 2023 at 14:10, Andrew Dunstan wrote:
> We'll email them once this is in. Most people are fairly reponsive.
I pushed the rename patch earlier.
How should we go about making contact with the owners? I'm thinking
it may be better coming from you, especially if you think technical
On 2023-02-14 Tu 17:32, David Rowley wrote:
On Wed, 15 Feb 2023 at 11:27, Andrew Dunstan wrote:
It's just occurred to me that this could break the buildfarm fairly
comprehensively. I just took a count and we have 74 members using
force_parallel_mode. Maybe we need to keep
On Wed, 15 Feb 2023 at 11:27, Andrew Dunstan wrote:
> It's just occurred to me that this could break the buildfarm fairly
> comprehensively. I just took a count and we have 74 members using
> force_parallel_mode. Maybe we need to keep force_parallel_mode as an
> alternative spelling for
On 2023-02-13 Mo 06:16, David Rowley wrote:
On Sat, 11 Feb 2023 at 04:34, Andrew Dunstan wrote:
On 2023-02-09 Th 15:25, David Rowley wrote:
Likely the hardest part to get right here is the new name. Can anyone
think of anything better than debug_parallel_query?
WFM
Thanks for chipping in.
On Sat, 11 Feb 2023 at 04:34, Andrew Dunstan wrote:
>
> On 2023-02-09 Th 15:25, David Rowley wrote:
> Likely the hardest part to get right here is the new name. Can anyone
> think of anything better than debug_parallel_query?
>
>
> WFM
Thanks for chipping in.
I've attached a patch which fixes
On 2023-02-09 Th 15:25, David Rowley wrote:
On Thu, 9 Feb 2023 at 21:20, John Naylor wrote:
Looks good at a glance, just found a spurious word:
+ "by forcing the planner into to generate plans which contains nodes "
Thanks for looking. I'll fix that.
Likely the hardest part to get right
On Thu, 9 Feb 2023 at 21:20, John Naylor wrote:
> Looks good at a glance, just found a spurious word:
>
> + "by forcing the planner into to generate plans which contains nodes "
Thanks for looking. I'll fix that.
Likely the hardest part to get right here is the new name. Can anyone
think of
On Thu, Feb 9, 2023 at 5:50 AM David Rowley wrote:
> Attached updated patch.
Looks good at a glance, just found a spurious word:
+ "by forcing the planner into to generate plans which contains nodes "
--
John Naylor
EDB: http://www.enterprisedb.com
On Thu, 9 Feb 2023 at 11:26, Tom Lane wrote:
>
> David Rowley writes:
> > I've attached a patch which does the renaming to debug_parallel_query.
> > I've made it so the old name can still be used.
>
> There's a better way to do that last, which is to add the translation to
> map_old_guc_names[].
David Rowley writes:
> I've attached a patch which does the renaming to debug_parallel_query.
> I've made it so the old name can still be used.
There's a better way to do that last, which is to add the translation to
map_old_guc_names[]. I am not very sure what happens if you have multiple
GUC
On Thu, 2 Feb 2023 at 01:24, John Naylor wrote:
>
>
> On Wed, Feb 1, 2023 at 6:41 PM David Rowley wrote:
> >
> > 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
On Wed, Feb 1, 2023 at 6:41 PM David Rowley wrote:
>
> 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
On Thu, 30 Jun 2022 at 00:31, Justin Pryzby 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,
On Wed, 29 Jun 2022 at 18:57, Laurenz Albe wrote:
> Perhaps some stronger wording in the documetation would be beneficial.
> I have little sympathy with people who set unusual parameters without
> even glancing at the documentation.
My thoughts are that the documentation is ok as is. I have a
On Thu, 30 Jun 2022 at 00:31, Justin Pryzby wrote:
> 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 wasn't aware of that change. Thanks for highlighting it.
Maybe it's worth seeing if fewer
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
On Wed, 2022-06-29 at 15:23 +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
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
23 matches
Mail list logo
