Re: PG 18 relnotes and RC1

On Fri, Sep 19, 2025 at 01:04:26PM -0400, Jonathan S. Katz wrote:
> On 9/19/25 12:50 PM, Nathan Bossart wrote:
>> +      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?
> 
> Will throw out the "we can just remove it" option like further down in the
> release notes, but figure we've put the AIO terminology out there enough it
> may be good to assign the too. Anyway, if we keep it, I'd suggest
> "asynchronous I/O (AIO)" given it's modifying that.

Done.

> For "other operations", the release notes have "etc." in them. But if we
> want to hedge, we can do:
> 
> ...that can improve performance of operations, including sequential scans,
> bitmap heap scans, and vacuums."

I left this alone.

>> +      <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.
> 
> OK with "retains", and OK w/dropping "through upgrade".

Done.

>> +      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."
> 
> Agreed switching to active voice.

Done.

>> +      <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".
> 
> I think "during" and "just-in-time" are equivalent here. Also wanted to be
> sensitive to the fact we already have a feature called "just-in-time"/"JIT"
> for compilation, and didn't want people to confuse the two.

I left this alone, too.

-- 
nathan