Find out whether pg_stat_statements is lying to you
Three ways the extension quietly reports nothing useful: the library is loaded but the extension was never created in that database, a reload leaves pg_stat_statements.max unchanged, and eviction drops your worst query — 250 fingerprints against max=100 left 97 entries, dealloc 16, and a 461 ms query gone.
Problem
What you're actually looking at
The symptom as it shows up on a real server.
Every tuning runbook starts with pg_stat_statements, so a silent failure here misdirects everything downstream. It fails silently in three distinct ways, and none of them raises an alert: the view does not exist in the database you are querying, the setting you changed never took effect, or the entry you needed was evicted to make room. In all three the dashboard looks calm and the conclusion drawn is that there are no slow queries.
Meridian's monitoring shows no slow queries while users report slow pages. The extension is in shared_preload_libraries, so everyone assumes the data is trustworthy.
In plain English
pg_stat_statements is the notebook PostgreSQL keeps about which queries cost what. Three things can make that notebook useless without anyone being told. It can not exist in the database you are reading — loading the code is not the same as creating the view, and the view has to be created in each database. Its size limit can be one you never actually applied, because that particular setting needs a full restart rather than a reload. And it has a fixed number of pages: when it runs out, it tears out old entries to make room, and the rare, catastrophic query is exactly the sort that gets torn out.
Full runbook for this incident
- The full identify checklist — the exact signals that tell you it's this incident
- Every diagnostic query; PostgreSQL 18 output is attached only to the steps we captured
- The resolution path and the pitfalls that make it worse
- Mitigation steps to stop it recurring, plus a verify-you're-done query
More in this category
Other Observability runbooks
Neighbouring incidents that share the same diagnostic surface.
Connected
How this connects to the rest of the library
A live view of this page's real cross-references — what explains it, what fixes it, what to tune, and where to go next. Every link is an authored relationship, not a guess.
Fixes these errors