Guard a Fix So the Slow Plan Cannot Come Back Quietly
Query performance regresses silently: someone drops the index, the data distribution shifts, the statistics go stale, or a new ORM call reintroduces the N+1 you removed. A guard is something that will notice, a pg_stat_statements baseline you compare after each release, a test that asserts the plan for a critical query still uses the index, a check that an index's idx_scan count is not zero, or an assertion on the number of queries a request makes. Pick one guard per fix and write it the same day, because the person who will trip over the regression has not joined the team yet.
Questions this Concept answers
Why does query performance regress quietly rather than announcing itself?
J
jeremy
Video
Regression Testing SQL Queries with EXPLAIN ANALYZE Buffer Counts in PostgreSQL
SQL query performance can be regression-tested in CI by asserting on the buffer counts reported by `EXPLAIN (ANALYZE, BUFFERS)` rather than on wall-clock time or estimated cost: elapsed time is envir…