On Tue, May 14, 2024 at 03:39:26PM -0400, Melanie Plageman wrote: > On Thu, May 9, 2024 at 12:04 AM Bruce Momjian <br...@momjian.us> wrote: > > > > I have committed the first draft of the PG 17 release notes; you can > > see the results here: > > > > https://momjian.us/pgsql_docs/release-17.html > > I had two comments: > > -------- > I think the read stream item: > > "Allow the grouping of file system reads with the new system variable > io_combine_limit" > > Might be better if it mentions the effect, like: > > "Reduce system calls by automatically merging reads up to io_combine_limit"
Uh, as I understand it, the reduced number of system calls is not the value of the feature, but rather the ability to request a larger block from the I/O subsystem. Without it, you have to make a request and wait for each request to finish. I am open to new wording, but I am not sure your new wording is accurate. > ------- > For the vacuum feature: > > "Allow vacuum to more efficiently remove and freeze tuples" > > 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. > > 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 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. -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.