Feedback-ID: ia2694551:Fastmail
Date: Wed, 15 May 2024 10:38:20 +0200
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Bruce Momjian <bruce@momjian.us>
Cc: Melanie Plageman <melanieplageman@gmail.com>, 
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: First draft of PG 17 release notes
Message-ID: <202405150838.sg5ddcexyyf4@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <ZkQJQqrh_KcWlVdy@momjian.us>
Archived-At: <https://www.postgresql.org/message-id/202405150838.sg5ddcexyyf4%40alvherre.pgsql>
Precedence: bulk

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