Date: Tue, 14 May 2024 21:00:50 -0400
From: Bruce Momjian <bruce@momjian.us>
To: Melanie Plageman <melanieplageman@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: First draft of PG 17 release notes
Message-ID: <ZkQJQqrh_KcWlVdy@momjian.us>
References: <ZjxLJpnH4VMkOMmi@momjian.us>
 <CAAKRu_Y5rOmi0jXAfrrk0U18ZC3Z0xzyA3YxPd4wpxJmXkR3jg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAAKRu_Y5rOmi0jXAfrrk0U18ZC3Z0xzyA3YxPd4wpxJmXkR3jg@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/ZkQJQqrh_KcWlVdy%40momjian.us>
Precedence: bulk

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.