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