Re: PostgreSQL 18 GA press release draft - Mailing list pgsql-hackers

On 9/12/25 3:24 PM, Álvaro Herrera wrote:
> Hello,
> 
> Thanks for putting this together!  It's quite the monster.  I read
> through and found the following points worth mentioning:

Thank you!

> I think almost all of the non-stock section titles Are Lacking Case
> Title.

Putting this is as an example of "stylistic comment" ;)

>> The new [`io_method`](https://www.postgresql.org/docs/18/runtime-config-resource.html#GUC-IO-METHOD) setting lets
youtoggle between the AIO methods, including `worker` and `io_uring` (when built with PostgreSQL, available on certain
Linuxsystems), or you can choose to maintain the current PostgreSQL behavior with the `sync` setting. There are now
moreparameters to consider tuning with AIO, which you can [learn more about in the
documentation](https://www.postgresql.org/docs/18/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-IO).
> 
> I don't understand the "when built with PostgreSQL".  Did you mean to
> reference something else here?

I re-read it and realized it doesn't add much value, so I just removed it.

>> PostgreSQL 18 further accelerates query performance with features that automatically make your workloads faster.
Thisrelease introduces "skip scan" lookups on [multicolumn B-tree
indexes](https://www.postgresql.org/docs/18/indexes-multicolumn.html),which improves execution time for queries that
omitan `=` condition on one or more prefix index columns. It can also optimize queries that use `OR` conditions in a
`WHERE`to use an index, leading to significantly faster execution. There are also numerous improvements for how
PostgreSQLplans and executes table joins, from boosting the performance of hash joins to allowing merge joins to use
incrementalsorts.
 
> 
> introduces "skip scan" lookups ..., which improve
> (remove ending 's')

Good catch - I revised and s/, which/that/

> Actually I wonder if these two items (commits f278e1fe3 and 9d6db8bec)
> are actually worthy of being in the press release.  They are about using
> unique indexes that aren't btrees, but as I understand, in stock
> Postgres there isn't any other way to build unique indexes, so this is
> about allowing out-of-core index AMs to be used in these contexts.

Thanks for the analysis on this one. Upon reflection, I'm going to 
remove this item from the press release. I'll move the parallel GIN 
builds to the first paragraph.

> I think this should say "This release adds the PG_UNICODE_FAST local
> provider", or something like that, because ending in just
> "PG_UNICODE_FAST" seems to be unintelligible.

Heh, should have added "collation"; fixed.

>> ### Authentication and security features
> 
> In this section I would also mention that pgcrypto gained SHA-2 cipher
> for passwords (commit 749a9e20c979).

Cool - added:

Additionally, 
[`pgcrypto`](https://www.postgresql.org/docs/18/pgcrypto.html) now 
supports [SHA-2 encryption for password 
hashing](https://www.postgresql.org/docs/18/pgcrypto.html#PGCRYPTO-CRYPT-ALGORITHMS).

> My English grammar fails me here.  I would say "... now defaults to
> using", but maybe your "now defaults to use" is correct.

I'm OK to use "using" if it's simpler for translating.

> "The pg_createsubscriber **utility**" ?

Thanks; I thought I had that in originally.

>> Databases initialized with PostgreSQL 18 [`initdb`](https://www.postgresql.org/docs/18/app-initdb.html) now have
pagechecksums enabled by default. This can affect upgrades from non-checksum enabled clusters, which would require you
tocreate a new PostgreSQL 18 cluster with the `--no-data-checksums` option when using
[`pg_upgrade`](https://www.postgresql.org/docs/18/pgupgrade.html).
> 
> I'm not sure that the relnotes really need to explain how to use
> pg_upgrade.  To me it seems enough to say that initdb now creates
> checksum-enabled clusters by default.

I included it because I think this is a potential tripwire. I don't know 
what the universe of non-checksum enabled clusters is out there, but I 
expect that it's pretty large. I think this is helpful for folks who are 
less familiar with PostgreSQL operational and upgrade mechanics (after 
all, they may only upgrade once a year at best) so it's a little simple 
to discover. Plus, this will help to surface the method as something to 
note through whatever AI summarizing techniques people are using.

Thanks!

Jonathan