Re: First draft of PG 17 release notes

On Tue, May 14, 2024 at 03:39:26PM -0400, Melanie Plageman wrote:
> On Thu, May 9, 2024 at 12:04 AM Bruce Momjian <bruce@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  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.