EXPLAIN ANALYZE Explainer
Paste your PostgreSQL query plan and get plain English. Every node decoded — bottlenecks, full scans, row estimate errors, disk spills, and what to do about each one.
Tip: For the most useful output, run EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT) — this includes actual times, row counts, and cache hit stats.
Supports PostgreSQL text format. Get it with: EXPLAIN (ANALYZE, BUFFERS) SELECT ...
What it reads from your plan
Every metric extracted, translated, and flagged when it matters.
Bottleneck node
Automatically identifies which node is consuming the most time and highlights it in the breakdown.
Node types decoded
Seq Scan, Index Scan, Hash Join, Nested Loop, Sort, Materialize — every node explained in plain English with context.
Row estimate errors
Flags when the planner's estimate is 10x off from actual rows — the root cause of most bad query plans.
Disk spills
Detects sorts and hash joins that didn't fit in memory and spilled to disk — and tells you how to fix it with work_mem.
Cache hit ratio
Shows buffer hits vs disk reads. Low cache hit rate means your working set doesn't fit in shared_buffers.
Filter waste
Counts how many rows were read and discarded by Filter conditions — shows the exact gain possible from adding an index.
Frequently Asked Questions
How do I get EXPLAIN ANALYZE output in PostgreSQL?
Run: EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT) followed by your query. The BUFFERS option adds cache hit stats. Example: EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM orders WHERE status = 'active';
What does Seq Scan mean in PostgreSQL EXPLAIN?
A Seq Scan (Sequential Scan) means PostgreSQL read every row in the table from start to finish without using an index. On large tables this is slow. The fix is to add an index on the column(s) in your WHERE clause.
Why is my PostgreSQL query slow even with an index?
Common reasons include: stale table statistics (run ANALYZE), the planner underestimating rows and choosing a bad join type, the index not matching the query (e.g., function wrapping the column), or the hash table spilling to disk due to insufficient work_mem.