Re: Release 14 Schedule

On Wed, Sep 22, 2021 at 11:01 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
> > On Wed, Sep 22, 2021 at 6:30 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> I thought the point about FDWs was important because actual work (by
> >> FDW authors) is needed to make anything happen. The extra parallelism
> >> inside plpgsql functions doesn't require user effort, so I don't see
> >> that it needs to be called out separately.
>
> > True, but I'm willing to guess we have a lot more people who are using
> > stored procs with return query and who are going to be very happy
> > about them now being much faster in cases where parallelism worked,
> > than we have people who are writing FDWs..
>
> Certainly. But my sentence about "Numerous performance improvements"
> already mashes down dozens of other it-just-works-better-now
> performance improvements. Wny call out that one in particular?

Just my guestimate that that one is going to be one of the more
popular ones. But it is a guess. And I'm not feeling strongly enough
about it to argue that one - if you feel the one there now is more
important,t hen we go with it.

> If I had to pick out just one, I might actually lean towards mentioning
> 86dc90056, which might change users' calculus about how many partitions
> they can use. (But I may be biased about that.)

Ah, so you posting that led me to re-read the whole thing again, this
time directly after caffeine.

It starts mentioning parallel query and it finishes with parallel
query. At a quick glance that gave me the impression the whole
paragraph was about "things related to improvements of parallel
query", given how it started.

Knowing that, I'd leave the "numerous improvements for parallel
queries" and just drop the specific mention of FDWs personally. We we
want to call out something in particular at the end, I agree that
86dc90056 is probably a better choice than either of the other two for
being the called-out one.

> > My take on that is audience. It's an important feature for existing
> > users of PostgreSQL, and an important change over how the system
> > behaved before. They are more likely to read the release notes. The
> > press release is more about reaching people who are not already using
> > postgres, or who are so but more tangentially.
>
> Perhaps, but on those grounds, the business about reducing B-tree bloat
> doesn't belong in the press release either. Anyway I'm not sure the
> audiences are so different --- if I thought they were, I'd not have
> started from the press release.

True on the btree point.

> My feeling is that the initial summary in the release notes is meant
> to be a 10000-meter overview of what's new in the release. As soon
> as you get past that bullet list, you find yourself right down in the
> weeds, so an overview is good to have. The press release can afford
> to fly a little lower than 10000 meters, though not by all that much.

I'm not really sure of the value of having two different set of
summaries if they're basically targeting the same group. But now is
not the time to bikeshed about the overall structure I think, so I'm
fine keeping it that way. And if that is the target audience then yes,
it makes sense not to have something in the release notes summary
that's not in the press release. I would then argue for *including*
the emergency mode vacuum in the press release.

--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/