Re: First draft of PG 17 release notes

On Wed, May 15, 2024 at 4:38 AM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>
> On 2024-May-14, Bruce Momjian wrote:
>
> > On Tue, May 14, 2024 at 03:39:26PM -0400, Melanie Plageman wrote:
>
> > > I think that we need to more clearly point out the implications of the
> > > feature added by Sawada-san (and reviewed by John) in 667e65aac35497.
> > > Vacuum no longer uses a fixed amount of memory for dead tuple TID
> > > storage and it is not preallocated. This affects users as they may
> > > want to change their configuration (and expectations).
> > >
> > > If you make that item more specific to their work, you should also
> > > remove my name, as the work I did on vacuum this release was unrelated
> > > to their work on dead tuple TID storage.
> > >
> > > The work Heikki and I did which culminated in 6dbb490261 mainly has
> > > the impact of improving vacuum's performance (vacuum emits less WAL
> > > and is more efficient). So you could argue for removing it from the
> > > release notes if you are using the requirement that performance
> > > improvements don't go in the release notes.
> >
> > I don't think users really care about these details, just that it is
> > faster so they will not be surprised if there is a change. I was
> > purposely vague to group multiple commits into the single item. By
> > grouping them together, I got enough impact to warrant listing it. If
> > you split it apart, it is harder to justify mentioning them.
>
> I disagree with this. IMO the impact of the Sawada/Naylor change is
> likely to be enormous for people with large tables and large numbers of
> tuples to clean up (I know we've had a number of customers in this
> situation, I can't imagine any Postgres service provider that doesn't).
> The fact that maintenance_work_mem is no longer capped at 1GB is very
> important and I think we should mention that explicitly in the release
> notes, as setting it higher could make a big difference in vacuum run
> times.
>
> I don't know what's the impact of the Plageman/Linnakangas work, but
> since there are no user-visible consequences other than it being faster,
> I agree it could be put more succintly, perhaps together as a sub-para
> of the same item.
>
> What about something like this?
>
> <para>
> Lift the 1 GB allocation limit for vacuum memory usage for dead
> tuples, and make storage more compact and performant.
> </para>
> <para>
> This can reduce the number of index passes that vacuum has to perform
> for tables with many dead tuples, shortening vacuum times.
> </para>
> <para>
> Also, the WAL traffic caused by vacuum has been made more compact.
> </para>

I think this wording and organization makes sense. I hadn't thought of
using "traffic" to describe this, but I like it.

Also +1 on the Sawada/Naylor change being on the highlight section of
the release (as David suggested upthread).

- Melanie