Re: PostgreSQL 19 GA press release draft

On 11/7/26 3:36 PM, Lukas Fittl wrote:
> 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.

Here's another take, which I think aligns with your suggestions:

==
PostgreSQL 19 gives users better control over plan stability and query
performance with the new
[`pg_plan_advice`](https://www.postgresql.org/docs/19/pgplanadvice.html)
extension.
==

>> 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."?

Sure - I'm good with that (or something similar). Here was my attempt:

==
PostgreSQL 19 adds the
[`pg_plan_advice`](https://www.postgresql.org/docs/19/pgplanadvice.html)
extension, which allows stabilization of plan choices and the ability to
experiment 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)

Changed.

> Otherwise looks good - thanks for putting this together as always!
Thanks for the review!

Jonathan