Re: First draft of PG 17 release notes

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>

> > However, one of the preliminary commits for this f83d70976 does
> > change WAL format. There are three WAL records which no longer exist
> > as separate records. Do users care about this?

I don't think so.

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"You don't solve a bad join with SELECT DISTINCT" #CupsOfFail
https://twitter.com/connor_mc_d/status/1431240081726115845