PostgreSQL Plan Regression
Same SQL. Different plan. Very different production behavior.
Same SQL. Different plan. Very different production behavior.
Compare estimated vs actual rows and data distribution changes.
Generic/custom plan behavior can create parameter-sensitive regressions.
Tie plan changes back to deployment, statistics, data growth, version or configuration changes.
Do not force a plan before understanding why the optimizer changed its choice.
CREATE STATISTICS).Read-only. Run them during the problem window if you can; most of these views show current state, not history.
-- Tables with the most changes since their last analyze
SELECT relname,
n_live_tup,
n_mod_since_analyze,
last_analyze,
last_autoanalyze
FROM pg_stat_user_tables
ORDER BY n_mod_since_analyze DESC
LIMIT 10;
-- Then, in a safe environment, compare estimated vs actual rows on each plan node:
EXPLAIN (ANALYZE, BUFFERS) <the regressed query with representative parameters>;
-- To capture the plan production actually ran, use auto_explain:
-- auto_explain.log_min_duration = '500ms' (session_preload_libraries or shared_preload_libraries)See the measured generic-plan regression lab for a complete change, evidence and response sequence. If the regression started after a major version upgrade, check for missing optimizer statistics first.
Start with the problem and the evidence you already have. You will get a direct answer on whether a scoped investigation is the right next step.
Prefer to talk first? Book a 20-minute triage call.