Teuerste Abfragen finden (pg_stat_statements: Gesamt- und mittlere Zeit)
PostgreSQLPerformanceBefehl
-- By total time: queries consuming the most server time
SELECT queryid,
calls,
round(total_exec_time::numeric, 1) AS total_ms,
round(mean_exec_time::numeric, 2) AS mean_ms,
round(stddev_exec_time::numeric, 2) AS stddev_ms,
round((100 * total_exec_time / sum(total_exec_time) OVER ())::numeric, 1) AS pct_total,
rows / NULLIF(calls, 0) AS rows_per_call,
left(regexp_replace(query, '\s+', ' ', 'g'), 120) AS query
FROM pg_stat_statements
WHERE dbid = (SELECT oid FROM pg_database WHERE datname = current_database())
ORDER BY total_exec_time DESC
LIMIT 20;
-- By mean time per call: individually slow queries
SELECT queryid,
calls,
round(mean_exec_time::numeric, 2) AS mean_ms,
round(max_exec_time::numeric, 2) AS max_ms,
round(mean_plan_time::numeric, 2) AS mean_plan_ms,
left(regexp_replace(query, '\s+', ' ', 'g'), 120) AS query
FROM pg_stat_statements
WHERE calls >= 50
ORDER BY mean_exec_time DESC
LIMIT 20;Was es tut
Listet die normalisierten Abfragen, die in der aktuellen Datenbank die meiste Serverzeit verbrauchen, mit ihrem Anteil am Gesamtwert; die zweite Abfrage listet die langsamsten je Aufruf.
Wann einsetzen
Erste Anlaufstelle, wenn CPU-/IO-Last steigt oder Benutzer 'die Datenbank ist langsam' melden; um zu entscheiden, wo das Tuning beginnen soll.
Vorsicht
pg_stat_statements erfasst nichts, bis es in shared_preload_libraries eingetragen, der Server neu gestartet und CREATE EXTENSION in der Datenbank ausgeführt wurde. Die Werte sind seit dem letzten Reset kumuliert. Ein im Verhältnis zu mean_ms hoher stddev_ms zeigt, dass Plan oder Datenverteilung zwischen Aufrufen variieren. mean_plan_time wird nur mit pg_stat_statements.track_planning = on befüllt (Standard off; Aktivieren erzeugt Overhead). Um Abfragetexte anderer Benutzer zu sehen, braucht es Superuser oder die Rolle pg_read_all_stats.
Verwandte Einträge
- Abfragen finden, die Platten-I/O, Temp-Dateien und WAL verursachen (pg_stat_statements)
- Statistiken von pg_stat_statements zurücksetzen (alle oder eine einzelne Abfrage)
- Ausführungspläne langsamer Abfragen mit auto_explain protokollieren
- Plan im Detail lesen mit EXPLAIN (ANALYZE, BUFFERS, SETTINGS, WAL)
- Planregressionen per queryid erkennen (Snapshot-Vergleich von pg_stat_statements)
- Kapazität für Parallel Query und aktuelle Worker-Nutzung prüfen