At a glance
A ranked table of the statement shapes consuming the most total execution time over the last 24 hours, drawn from pg_stat_statements. This is the “where is my database time actually going?” leaderboard. The ranking is by total time, not per-call time, so it surfaces the queries that matter most in aggregate: a 20ms query run two million times outranks a 5-second query run twice, because the first is where your instance is genuinely spending its capacity.
What it tracks
The card lists the top queries bytotal_exec_time from pg_stat_statements over a rolling 24-hour window (24h), with each row showing the normalised statement text (literals replaced by $1, $2), call count, mean execution time, and total accumulated time. Ranking by total time is the key design choice: it directs optimisation effort at the statements that consume the most database capacity overall, which is usually a high-frequency query at moderate latency rather than a rare slow one. This is the natural drill-down whenever a percentile or rate card moves: when Query Latency p99 (ms) spikes or Slow-Query Rate % climbs, this table names the statement shapes responsible. Pair it with Buffer Cache Hit Rate % (a leader with heavy disk reads points at an indexing or cache gap) and Queries per Second (live) for traffic context. The first query to optimise is almost always the one at the top of this list, because shaving 30% off the statement that owns the most total time frees more capacity than fixing ten rare slow ones.
Reconciling against the source
Reproduce the ranking natively withSELECT queryid, calls, mean_exec_time, total_exec_time, query FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 10; on the monitored database. The raw view holds lifetime cumulative totals since the last pg_stat_statements_reset(), so it will differ from the card’s 24-hour window; reset the view or compare deltas to align. On managed services cross-check with Performance Insights top SQL (RDS / Aurora), Query Insights (Cloud SQL), or Query Store (Azure). Run EXPLAIN (ANALYZE, BUFFERS) on any leader to confirm the plan before optimising.