Re: PG 18 relnotes and RC1 - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: PG 18 relnotes and RC1
Date
Msg-id aM2Ju1jS2oqZv5LV@nathan
Whole thread Raw
In response to Re: PG 18 relnotes and RC1  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: PG 18 relnotes and RC1
List pgsql-hackers
On Fri, Sep 19, 2025 at 09:25:52AM -0500, Nathan Bossart wrote:
> I'm hoping to commit this around 20:00 UTC today, and I will be happy to
> address any feedback that folks have in the meantime.

Here's a v4.  The content is the same except for a typo fix, some
formatting adjustments that don't change anything in the generated page,
and a real commit message.  I'm okay with the content, but I figured I'd
note some thoughts:

+      An asynchronous I/O subsystem (AIO) that can improve performance of
+      sequential scans, bitmap heap scans, vacuums, and other operations.

I wondered whether we should put "(AIO)" before "subsystem", but I think
putting it next to "I/O" makes the line too busy.  Also, are there "other
operations", or is the rest of the list complete?

+      <link linkend="pgupgrade"><application>pg_upgrade</application></link>
+      now maintains optimizer statistics through upgrade.

I think "retain" might be a better verb than "maintain", but the meaning
seems clear either way.  Also, while we could probably omit "through
upgrade", the small amount of redundancy does (IMHO) reinforce the meaning
a bit.

+      Support for "skip scan" lookups that allow
+      <link linkend="indexes-multicolumn">multicolumn B-tree indexes</link> to
+      be used in more cases.

Passive voice.  Perhaps this should be "that allow using ... in more
cases."

+      <link linkend="sql-createtable-parms-generated-stored">generated columns</link>
+      that compute their values during read operations.  This is now the
+      default for generated columns.

I liked the phrase "just-in-time" for this because it expresses how it
works.  Perhaps we should squeeze that in before "during read operations".

-- 
nathan

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Having postgresql.org link to cgit instead of gitweb
Next
From: "Jonathan S. Katz"
Date:
Subject: Re: Having postgresql.org link to cgit instead of gitweb