Re: add default parallel query to v10 release notes? (Re: [PERFORM] performance drop after upgrade (9.6 > 10))

On Thu, May 24, 2018 at 08:00:25PM -0500, Justin Pryzby wrote:
> Moving to -hackers;
>
> On Sun, Jan 28, 2018 at 06:53:10PM -0500, Bruce Momjian wrote:
> > On Thu, Oct 26, 2017 at 02:45:15PM -0500, Justin Pryzby wrote:
> > > Is it because max_parallel_workers_per_gather now defaults to 2 ?
> > >
> > > BTW, I would tentatively expect a change in default to be documented in the
> > > release notes but can't see that it's.
> > > 77cd477c4ba885cfa1ba67beaa82e06f2e182b85
> >
> > Oops, you are correct. The PG 10 release notes, which I wrote, should
> > have mentioned this. :-(
>
> I just saw your January response to my October mail..
>
> Maybe it's silly to update PG10 notes 9 months after release..
> ..but, any reason not to add to v10 release notes now (I don't know if the web
> docs would be updated until the next point release?)

So I did some research on this, particularly to find out how it was
missed in the PG 10 release notes. It turns out that
max_parallel_workers_per_gather has always defaulted to 2 in head, and
this was changed to default to 0 in the 9.6 branch:

commit f85b1a84152f7bf019fd7a2c5eede97867dcddbb
Author: Robert Haas <rhaas(at)postgresql(dot)org>
Date: Tue Aug 16 08:09:15 2016 -0400

Disable parallel query by default.

Per discussion, set the default value of max_parallel_workers_per_gather
to 0 in 9.6 only. We'll leave it enabled in master so that it gets
more testing and in the hope that it can be enable by default in v10.

Therefore, there was no commit to find in the PG 10 commit logs. :-O
Not sure how we can avoid this kind of problem in the future.

The attached patch adds a PG 10.0 release note item about this change.
I put it at the bottom since it is newly added.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +