Thread: PostgreSQL 18 Beta 1 release announcement draft

Hi,

Attached is a draft of the PostgreSQL 18 Beta 1 release announcement. 
The goal of this announcement is to introduce the new capabilities 
planned for PostgreSQL 18 and give users an idea of areas we'd like to 
see tested.

Please check for accuracy and if there are glaring omissions (happy to 
have the discussion on what to include in here, though note it's not 
possible to list everything in here). If a description is unclear or 
there are typos, I'm also happy to modify it; that said, for these 
suggestions I'm looking for recommendations that bring better clarity to 
a description vs. nitpicking over phrasing.

While I can make changes up until 2025-05-08 12:00 UTC, I won't be able 
to make anything substantive past 2025-05-08 02:00 UTC (especially 
because there's also the regular release this week!), so please have all 
feedback in by  2025-05-08 02:00 UTC.

Thanks - and thanks to everyone for their hard work on this release - 
I'm very excited for PostgreSQL 18!

Jonathan

On Mon, May 5, 2025 at 3:07 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
>
> Hi,
>
> Attached is a draft of the PostgreSQL 18 Beta 1 release announcement.
> The goal of this announcement is to introduce the new capabilities
> planned for PostgreSQL 18 and give users an idea of areas we'd like to
> see tested.
>
> Please check for accuracy and if there are glaring omissions (happy to
> have the discussion on what to include in here, though note it's not
> possible to list everything in here). If a description is unclear or
> there are typos, I'm also happy to modify it; that said, for these
> suggestions I'm looking for recommendations that bring better clarity to
> a description vs. nitpicking over phrasing.

One small piece of feedback on this:

"PostgreSQL 18 adds support for using "skip scan" lookups on
multicolumn B-tree indexes, which can result in faster execution times
for queries with multiple conditions."

I don't think that this is quite right; there doesn't have to be
multiple conditions involved in the query (though it *is* true that
skip scan can only be used with a multicolumn B-tree index). The
typical skip scan involves a query whose predicate has only a single
"=" condition, which is on the second column from a multicolumn index.
Typically, the first index column won't appear in the query predicate
at all -- it is wholly omitted, and yet the index can be scanned
reasonably efficiently when there aren't too many distinct values in
the leading/skipped column. (Of course it can be a lot more
complicated than this, but I'm just talking about the typical, simple
case.)

I suggest something closer to:

"PostgreSQL 18 adds support for using "skip scan" lookups on
multicolumn B-tree indexes, which can result in faster execution times
for queries that omit a "=" condition on one or more prefix index
columns."

There's a real danger in users confusing skip scan for loose index
scan, which is actually quite a different feature. Many hackers have
made the same mistake in the past. ISTM that specifically describing
how the feature applies to queries that omit an "=" condition makes
this misunderstanding less likely to occur.

--
Peter Geoghegan

Hi,

On Mon, May 05, 2025 at 03:07:01PM -0400, Jonathan S. Katz wrote:
> Hi,
> 
> Attached is a draft of the PostgreSQL 18 Beta 1 release announcement.

Thanks for working on it!

One small feedback on this:

"
and now shows per-connection statistics on I/O utilization
"

I think we can add WAL to the game, something like:

"
and now shows per-connection's I/O and WAL statistics 
"

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

On 2025-May-05, Jonathan S. Katz wrote:

> ### Other Highlights
> 
> Starting with PostgreSQL 18, data checksums, which are used to validate the integrity of stored data, are now enabled
bydefault on new PostgreSQL clusters. You can choose to disable this behavior using the `initdb --no-data-checksums`
command.
> 
> `pg_createsubscriber` now supports an `--all` flag so you can create logical replicas for all databases in an
instancewith a single command. Additionally, PostgreSQL 18 lets you create the schema definition of a foreign table
usingthe definition of a local table using the `CREATE FOREIGN TABLE ... LIKE` command.
 

In this section I would add the work on not-null and NOT ENFORCED
constraints, not because I think they are very important, but because
they have the potential to break stuff; and if they do, it would be very
useful to know before GA.  Maybe something like

  Some constraint features have been revised: foreign-key and check
  constraints can now be made NOT ENFORCED and altered into
  enforceability; not-null constraints now preserve their names as
  mandated by the SQL-standard, support the NOT VALID and NO INHERIT
  clauses, as well as behave more consistently on inheritance situations.


Now that I look again, I see no mention of temporal UNIQUE, PRIMARY KEY
and FOREIGN KEY constraints (commits fc0438b4e805 and 89f908a6d0ac).  I
think they are a very important feature, perhaps they even warrant a
section of their own.  So maybe I'd suggest to add a section
"### Constraints" and put all these things in there.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/