Why it matters
EXPLAIN ANALYZE tells you exactly how a query ran, but the output is dense: nested steps, costs, per-loop times that have to be multiplied out, and the one line that matters buried in the middle. The usual problems hide in it: a sequential scan that reads 100,000 rows to keep 1,000, a planner estimate that's off by 100 times, a sort that spilled to disk.
This visualiser reads the plan, rebuilds its tree, and works out each step's own time by taking its children's time away from its own, allowing for loops. It compares estimated and actual rows at every step and flags the patterns that usually explain a slow query, with a suggestion for each: an index on the filtered columns, ANALYZE or extended statistics for bad estimates, more work_mem for spills. They're phrased as things to test, because only your data can confirm them. Unlike hosted plan visualisers, nothing is uploaded or kept.
How it works
- InputEXPLAIN output from PostgreSQL or MySQL
- In your browserOwn time, loops and estimates per step
- OutputThe slow step, bad estimates and index ideas
Where it fits in a designer's workflow
- Plan
- Design
- Build
- Test
- Launch
By the numbers
Show the numbers as a table
| Step | Own time (ms) | Share (%) | Rows expected | Rows actual | Loops |
|---|---|---|---|---|---|
| Seq Scan on orders | 161.12 | 85.9 | 12 | 1468 | 1 |
| Index Scan on order_items | 22.02 | 11.7 | 98 | 4 | 1468 |
| Nested Loop | 2.635 | 1.4 | 1174 | 5876 | 1 |
| HashAggregate | 1.536 | 0.8 | 100 | 112 | 1 |
| Sort | 0.108 | 0.1 | 100 | 112 | 1 |
How to use it
- Run EXPLAIN (ANALYZE, BUFFERS) on your query in PostgreSQL, or EXPLAIN ANALYZE in MySQL 8.
- Paste the whole output.
- Read the summary and the slowest step, then the findings.
- Test the suggestions on a copy of the data, and compare the new plan.
FAQ
What's the difference between EXPLAIN and EXPLAIN ANALYZE?
EXPLAIN shows the plan with the planner's estimates. EXPLAIN ANALYZE also runs the query and records real times and row counts, which is what you need to find the slow step. It really runs the query, so wrap writes in a transaction you roll back.
Why is a node's own time different from its actual time?
A node's actual time includes everything below it, and it's per loop. Own time is the node's total (time multiplied by loops) minus its children's totals, which is the time spent in that step alone.
Why does a bad row estimate matter?
The planner picks join types and orders from its estimates. If it expects 12 rows and gets 1,468, it may choose a nested loop that runs its inner side 1,468 times instead of one hash join. ANALYZE refreshes statistics; CREATE STATISTICS helps when columns are correlated.
Will the suggested index definitely help?
Not definitely. It's based on the columns the scan filters on, equality columns first. Create it on a copy of your data and check the new plan; also weigh the cost of maintaining it on writes.
Is my plan uploaded?
No. It's parsed in your browser and nothing is stored.
