1. Run this query
Read-only. Needs the pg_stat_statements extension (on by default on most managed Postgres). Postgres 13 or later; on 12 or earlier replace total_exec_time, mean_exec_time and stddev_exec_time with total_time, mean_time and stddev_time and drop wal_bytes.
In psql: \copy ( …query… ) TO 'statements.csv' WITH CSV HEADER. Any SQL client's "export as CSV" works.
2. Paste the result
Choose a file or paste CSV text, then click Analyze.
Result
Where the time goes
| # | Share | Cumulative | Total | Calls | Mean | Query | Flags |
|---|
What to look at first
What fixing the top queries would be worth
| If the top … | were 2× faster | were 10× faster |
|---|
Share of total database time saved, assuming nothing else changes. It is arithmetic on the counters, not a forecast.
Tables touched by the most time
| Table | Query shapes | Time in queries touching it | Calls |
|---|
Tables are read from FROM, JOIN, UPDATE and INTO clauses and are approximate. A query touching two tables counts toward both, so these rows do not add up to the total.
The rules, and what they leave out
- Ranking — by total execution time. Entries that differ only in IN-list length, VALUES row count, comments or parameter numbers are merged into one shape.
- Hot — 5% or more of all database time.
- Chatty (N+1 suspect) — a SELECT with at least 1,000 calls and at least 10% of all calls, 2 ms or less per call and about one row per call.
- Cold — at least 100 MB read into shared buffers and a hit ratio below 95%. Reads can still be served by the OS cache.
- Temp spill — at least 10 MB written to temporary files.
- Slow — 250 ms or more per call over at least 10 calls. Swings — standard deviation at least 3× the mean (mean 10 ms or more). Many rows — 10,000 or more rows per call.
- Reconciles. Shares add to 100%, and merged calls and time equal the sum of the entries they came from.
- Not modelled: plans, indexes, locks, the application, replicas, and how long the counters have been collecting. Treat each flag as a reason to run EXPLAIN (ANALYZE, BUFFERS), not as a diagnosis.
Common questions
How do I find the slowest queries in Postgres?
Enable the pg_stat_statements extension, run the query on this page, and paste the CSV here. Queries are ranked by total execution time, which is what the database actually spent, not by how slow one call felt. A query that takes 2 ms but runs three million times costs more than one that takes two seconds and runs ten times.
What does pg_stat_statements measure?
For every normalised query shape it keeps the number of calls, total and mean execution time, rows, shared-buffer hits and reads, temp-file blocks and (on Postgres 13 and later) WAL bytes. The counters accumulate since the last reset, so a busy week and a quiet week can look the same. Reset them before a test if you want a clean window.
What is an N+1 suspect?
A single-row SELECT that runs far more often than anything else, returns about one row per call and takes only a millisecond or two. The tool cannot see your application, so it only says the pattern fits. If one page load or API request issues the lookup in a loop, batching the ids into one query with = ANY($1) or a join usually removes most of the calls.
Why are several entries merged into one?
pg_stat_statements stores a separate entry for each length of an IN list and each number of VALUES rows, so one query can be spread over dozens of entries. This tool merges entries that differ only in those lengths, comments or parameter numbering, and tells you how many it merged.
Does the tool connect to my database?
No. You run one read-only query and paste the result. The text is parsed in your browser and is not sent anywhere. Query text can contain table names and, if the application did not parameterise a value, literal data, so look at the paste before you share it with anyone.
What does it not see?
Query plans, indexes, lock waits, what the application does around a query, replicas, and how long the counters have been collecting. A flag is a reason to run EXPLAIN (ANALYZE, BUFFERS) on that query, not a diagnosis.
Is this database advice?
No. It applies fixed rules to the text you provide. You are responsible for checking its output and for any change you make to your database.