Re: PostgreSQL 19 GA press release draft

From: Lukas Fittl <lukas(at)fittl(dot)com>
To: "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>
Cc: Joel Jacobson <joel(at)compiler(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: PostgreSQL 19 GA press release draft
Date: 2026-11-07 20:36:22
Message-ID: CAP53PkxwC1AgygRp2T6hsNVnrWEDiZQmyikp5P2biUx=ycX9ng@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Jonathan,

> Mission-critical usage of PostgreSQL continues to rapidly rise, and
> PostgreSQL 19 responds to this by simplifying both administration and
> development for these workloads at scale. This release introduces the
> [`REPACK (CONCURRENTLY)`](https://www.postgresql.org/docs/19/sql-repack.html)
> command so users can optimize tables for their current workload without
> disruption to ongoing operations. PostgreSQL 19 also lets users provide their
> own guidance to the query planner using the new [`pg_plan_advice`](https://www.postgresql.org/docs/19/pgplanadvice.html)
> extension. Developers will find many delightful features in this release,
> from support for "read-your-writes" consistency on standbys to "get or create"
> behavior that saves a network round trip.

I feel like "lets users provide their own guidance to the query
planner" is not the right high level pitch for pg_plan_advice - it was
created with the motivation/perspective of plan stability (i.e. give
me the same plan again that you gave me previously), and intentionally
tried to steer away from the "give Postgres a hint" perspective.

That said, we're a bit character constrained in the intro. The
simplest edit I can think of is to just drop the "their own" wording
in that sentence, so its less about what the user thinks is right.

CCing Robert in case he hadn't seen this yet and has thoughts.

> The PostgreSQL query planner usually picks an efficient plan for each query, but
> the plan can change as your data changes, and sometimes the new plan is slower.
> PostgreSQL 19 adds the [`pg_plan_advice`](https://www.postgresql.org/docs/19/pgplanadvice.html)
> extension, which provides a "plan advice" language to describe, reproduce, and
> adjust the decisions the planner makes. The companion
> [`pg_stash_advice`](https://www.postgresql.org/docs/19/pgstashadvice.html)
> extension stores advice and automatically applies it to queries based on their
> query identifier, so you can fix a slow plan without changing your application.

What if we reword this so it reads "PostgreSQL 19 adds the
pg_plan_advice extension, which allows stabilization of plan choices,
as well as experimenting with different plans using the "plan advice"
mini-language."?

> PostgreSQL 19 also reports the amount
> of WAL written for full-page images in [`pg_stat_wal`](https://www.postgresql.org/docs/19/monitoring-stats.html#PG-STAT-WAL-VIEW),
> `EXPLAIN (ANALYZE, WAL)`, and vacuum and analyze logs.

Maybe "and in vacuum and analyze log events."? (since we don't have
dedicated vacuum/analyze log files)

Otherwise looks good - thanks for putting this together as always!

Thanks,
Lukas

--
Lukas Fittl

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jonathan S. Katz 2026-11-07 20:53:32 Re: PostgreSQL 19 GA press release draft
Previous Message Jim Jones 2026-11-07 20:30:04 XMLTable treats a column of a domain over xml as a non-xml column