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
