Re: PostgreSQL 18 GA press release draft

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 you toggle between the AIO methods, including `worker` and `io_uring` (when built with PostgreSQL, available on certain Linux systems), or you can choose to maintain the current PostgreSQL behavior with the `sync` setting. There are now more parameters 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. This release 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 omit an `=` 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 PostgreSQL plans and executes table joins, from boosting the performance of hash joins to allowing merge joins to use incremental sorts.
>
> 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 page checksums enabled by default. This can affect upgrades from non-checksum enabled clusters, which would require you to create 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