On Wed, May 15, 2024 at 4:38 AM Alvaro Herrera <alvhe...@alvh.no-ip.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
