Why this problem matters
One slow query sample may not be the largest source of total system load. Frequently executed moderate-cost statements can consume more resources than rare outliers.
How to diagnose it
Review calls, total execution time, mean time, and row counts together in pg_stat_statements. Normalized statements hide parameter values, and counters can be reset.
The query works when the pg_stat_statements extension is installed and accessible to the calling role. Interpret cumulative times within the statistics collection period.
SELECT queryid, calls, total_exec_time, mean_exec_time, rows,
left(query, 300) AS query
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 20;A safe solution approach
Select statements with high aggregate impact and business importance first. Validate index, SQL, or schema changes with realistic parameter distributions and EXPLAIN plans.
Why continuous monitoring matters
moon helps continuously monitor PostgreSQL statement trends with low overhead. Slack, PagerDuty, or webhook alerts can route new query regressions to the team.
Frequently asked questions
Is the highest mean_exec_time always the first priority?
No, an infrequently called statement may have little aggregate impact. Evaluate mean time against calls, total time, and business importance.
How does moon help with this problem?
moon continuously observes SQL Server, PostgreSQL, and MongoDB signals, helping teams evaluate the problem as a trend instead of relying on a one-time check.