On Mon, May 05, 2025 at 03:07:01PM -0400, Jonathan S. Katz wrote: > Before PostgreSQL 18, an important step after performing a major version > upgrade was to run the `ANALYZE` to generate statistics, which is a > critical component of helping PostgreSQL to select the most efficient > query plan. Based on the size and overall activity of a PostgreSQL > cluster, this could be a time consuming process, and potentially impact > query performance until the process completed. PostgreSQL 18 introduces > the ability to keep planner statistics through a major version upgrade, > removing the need to perform the analyze and help an upgraded cluster to > get to its expected performance state sooner once it's available.
To nitpick, the last sentence isn't totally accurate. Folks still need to analyze tables for which stats were not transferred (e.g., extended stats), and we additionally still recommend a database-wide analyze to update the cumulative stats that autovacuum uses, which are also not transferred. We might just want to remove the "removing the need to perform the analyze" part and focus on the benefits of transferring most of the stats. > Additionally, `pg_upgrade`, the utility used to facilitate a major > version upgrade, added several performance enhancements to help > accelerate upgrades with many objects, such as tables and sequences. This > release adds the `--jobs` flag, which allows pg_upgrade to process its > checks in parallel, and the `--swap` flag, which swaps upgrade > directories instead of copying, cloning, or linking files. The --jobs flag has existed for a while. What v18 does is parallelize gathering cluster information and performing cluster checks, and it uses the pre-existing --jobs option to determine how parallel to do these things. > This release deprecates `md5` password authentication in favor of using > SCRAM authentication that was first added in PostgreSQL 10. IMHO we should emphasize that MD5 password support will be removed in a future release and that users should migrate to something else soon. I'm imagining it'll still be at least a couple of years before I muster up the courage to actually propose removing MD5 support, but I think it's important to broadcast our intent here. -- nathan
