Feature · /query-summary
查询摘要
数据库执行过的每条查询规范化后,按真正影响最大的优先排序。
In one line
前 N 条规范化查询,附 p50 / p95 / p99 延迟、QPS、总耗时、扫描行数与计划变更历史。
What you get
- Normalized query digests across Postgres / MySQL / MongoDB / Oracle / SQL Server
- Latency percentiles (p50, p95, p99, max) updated every 15s
- Total time, calls, rows touched, plan changes, error rate per signature
- Group by app, host, database, schema, role, or any custom tag
- Drill from signature → individual executions → wait-event flame graph
- 30/90/365-day retention depending on plan
vs Datadog DBM
FAQ
How is a query 'normalized'?+
We strip literals, deterministically hash the parameterized form (md5 in Postgres, query_id in MySQL 8+, query digest in MongoDB), and treat that hash as the signature. Same logic Datadog uses.
Does this work without pg_stat_statements?+
For Postgres, no — pg_stat_statements is the source of truth. We auto-detect it on first connect and tell you what's missing.
What about MongoDB?+
We use $currentOp + the MongoDB profiler, normalized to a query shape hash. No driver changes required.
Related reading
Postgres
pg_stat_statements: the complete 2026 guide
Every column, every gotcha, the queries you should run today, and why pg_stat_statements is still the most useful 80 lines of telemetry in Postgres — even with five new alternatives in 2026.
Postgres
Postgres slow queries: 12 causes and how to find each one
A field-tested playbook for diagnosing a slow Postgres query in production — from missing indexes to plan flips to bloated tables — with the SQL to find each cause and the fix.
Postgres
Why your Postgres p99 latency lies — and what to track instead
p99 over 1m windows is the most-displayed and most-misleading number on every DBM dashboard. Here's the histogram math, the seasonality math, and a saner default.