public inbox for [email protected]
help / color / mirror / Atom feedFrom: Bruce Momjian <[email protected]>
To: Melanie Plageman <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: First draft of PG 17 release notes
Date: Tue, 14 May 2024 21:00:50 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAAKRu_Y5rOmi0jXAfrrk0U18ZC3Z0xzyA3YxPd4wpxJmXkR3jg@mail.gmail.com>
References: <[email protected]>
<CAAKRu_Y5rOmi0jXAfrrk0U18ZC3Z0xzyA3YxPd4wpxJmXkR3jg@mail.gmail.com>
On Tue, May 14, 2024 at 03:39:26PM -0400, Melanie Plageman wrote:
> On Thu, May 9, 2024 at 12:04 AM Bruce Momjian <[email protected]> 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 <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
view thread (146+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: First draft of PG 17 release notes
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox