Slow query monitoring
Slow query monitoring is most useful when it tells you what changed. A static list of slow SQL is a start, but production teams need baselines, deploy comparisons, plans, and enough context to fix the right thing.
A query is called often enough that small regressions matter
Mean execution time looks fine but p95 is getting worse
Rows returned stay flat while blocks read increase
A release changes a query's filter or join behavior
The same normalized query behaves differently for different tenants
A query that is moderately slow and called constantly may matter more than a rare outlier.
SELECT query, calls, total_exec_time, mean_exec_time, rows
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 20;Slow query logs are useful for individual outliers. pg_stat_statements is better for normalized trends and regressions.
ALTER SYSTEM SET log_min_duration_statement = '500ms';
SELECT pg_reload_conf();MonPG keeps query history so slow query regressions can be compared to earlier baselines.
Query pages connect timing, calls, rows, blocks, WAL, and related index signals.
Alerts can focus on regression and impact instead of noisy one-off slow statements.
Hands-on setup, integration, and troubleshooting guides from the MonPG product docs.
Threshold, pattern, query-metric, and custom SQL rules — when to use each.
Wire alerts to where your team already pays attention.
The one-page fleet summary. Active alerts, connection pressure, slowest queries, top size consumers.
Drill into any metric over any time range with full chart controls.
The Queries page is how you find performance outliers. Columns explained + filtering tips.
Diff this hour vs. previous hour, today vs. yesterday — find what regressed.
How Query Advisor parses captured plans and what the bottleneck labels mean.
Proposes indexes for queries that need them, flags indexes that aren't being used.
Benchmark 48 HNSW configurations against your real pgvector data in 10 minutes. Get the optimal m, ef_construction, and ef_search plus zero-downtime migration SQL.
Paste EXPLAIN ANALYZE output and get an incident-style read of the plan: planner estimate drift, loop explosions, disk spills, buffer pressure, and the evidence SQL to prove the fix.
Model a proposed PostgreSQL index as a production rollout: DDL shape, lock level, WAL pressure, write amplification, replica lag risk, validation SQL, and rollback criteria.
MonPG gives teams query history, alerts, index guidance, vacuum visibility, replication signals, and cloud PostgreSQL monitoring in one place.
Start free