UpgradesadvancedPro runbook

Run pg_upgrade and survive the statistics cliff

A real 16.15 to 17.11 upgrade kept every row and threw away every statistic: pg_stats went to 0 rows, reltuples to -1, and one query's estimate collapsed from 8,930 to 774 while the true count stayed 9,075, turning an index-only scan into a bitmap heap scan until ANALYZE ran.

Problem

What you're actually looking at

The symptom as it shows up on a real server.

pg_upgrade is fast because it does not rewrite data, and the speed is what everyone plans around. What the plan usually omits is that optimizer statistics are not carried across. The cluster comes up with correct data and an empty statistical picture of it, so the planner reverts to defaults and picks plans it would never have chosen the day before. The upgrade is judged a success at the moment the outage window closes, and the regression arrives with the first production traffic.

Meridian upgrades a busy cluster inside a short maintenance window. Everything starts, row counts match, and the application is slower than it was before the upgrade.

Simple terms

PostgreSQL keeps a summary of what your data looks like, how many rows, how many distinct values, which values are common, and the planner uses that summary to choose how to run a query. A major-version upgrade moves your data but not that summary. So the new server has all your rows and no idea what is in them, and it guesses. The guesses are bad in the specific way that matters: rare values look common, so the planner stops using the index that made the query fast. Rebuilding the summary is one command, and it is the step people skip because the upgrade already looked finished.

ProCaptured evidence where the run produced it

Full runbook for this incident

The scenario above is free. What Pro unlocks is the fix: how to identify run pg_upgrade and survive the statistics cliff, the exact SQL to trace it, PostgreSQL 18 output for the steps we captured, the resolution path, and how to stop it recurring.
  • The full identify checklist, the exact signals that tell you it's this incident
  • Every diagnostic query; lab output is attached only to the steps we actually captured
  • The resolution path and the pitfalls that make it worse
  • Mitigation steps to stop it recurring, plus a verify-you're-done query

Card required. Cancel before day 7 and you are not charged.

Compare plans

ShareLinkedInX

Need the full procedure?

Pro runbooks finish the incident path

Free runbooks teach the shape. Pro opens the full step transcript, edge cases, and prevention depth.

FollowSubstackLinkedInnew errors · lab notes · hiring loops