Slow-query triage on production

Situation

The app is slow, the on-call engineer doesn’t know this database, and you need facts — not guesses — before touching anything.

Commands

pgdba check --connection prod
pgdba why connection.max_connections     # drill into one finding
pgdba check --explain-flag skip_heavy    # what any flag does

What pgdba does

One read-only session ranks what is actually hurting: slow queries from pg_stat_statements (with plan-shape evidence), cache-hit, connection saturation, bloat, index bloat. Every finding carries a plain-language why, the cost of ignoring, an ignore-if, and ready-to-review remediation SQL.

Done looks like

A pgdba-report.md you can paste into the incident doc: ranked findings with IDs (duty.check), severities, and remediation — and the on-call knows exactly which two actions matter first.

On managed hosts (RDS, Cloud SQL)

No superuser, no ALTER SYSTEM — pgdba adapts: privilege-sensitive checks degrade instead of erroring, write remediation is refused per finding and recorded in the audit log, and pooled profiles (pooled = true) enforce the safety contract with SET LOCAL. Same ranked report, minus the advice a managed host cannot act on.