🧐Reading Query EXPLAIN Plans

Work out how far the plan's estimated rows sit from the actual rows, and what each plan item means.

A Seq Scan reads the table from start to finish. When the rows you want make up a large share of the table this is the faster choice, so seeing it is not a problem in itself. Seeing it on a big table while fetching only a few rows means no suitable index exists or none was used.

Each database shows plans differently

DatabaseCommandOutput shape
PostgreSQLEXPLAIN and EXPLAIN ANALYZEA node tree whose nesting is shown by indentation
MySQL and MariaDBEXPLAIN and EXPLAIN ANALYZEA table summarising access methods, or a tree form
SQLiteEXPLAIN QUERY PLANA short list with one scan or search per line

Item names and layout change between versions even within one database. This tool does not interpret a pasted plan; it works only from the numbers you read off the plan yourself, and it does not recommend indexes.

You Might Also Need

🔭

SQL WHERE Clause Builder

WHERE clause with quotes escaped

 🗂️

SQL ORDER BY Builder

Multi-key sort with NULL placement

About this tool

The first thing to check in an execution plan is how far the estimated row counts sit from the actual ones. The planner picks scan methods and join methods from estimates built on statistics, so when those numbers are badly wrong every choice above them goes wrong as well. Read the two figures off each node, type them in, and this tool works out the misestimate factor and names the node that drifted furthest.

PostgreSQL ANALYZE output prints both estimated rows and actual rows per loop, so entering the loop count multiplies both into totals and the mismatch ratio stays the same as per loop. There is no authoritative threshold for how large a misestimate factor becomes a problem, so no figure is suggested here; enter the threshold your team uses and nodes past it are counted. Plan item meanings are summarised using PostgreSQL naming as of October 2026.

This tool does not interpret a pasted plan. Plan formats differ between databases and versions and item names change, so it takes only the numbers you read off the plan yourself. It does not recommend indexes, rewrite queries or predict run times.

Frequently asked questions

Why does the gap between estimate and actual matter?

The planner chooses scan and join methods from the estimated row counts. When one row is estimated and tens of thousands arrive, a plan that chose a Nested Loop runs its inner side tens of thousands of times. Finding the badly misestimated nodes first is therefore the right order of work.

Can the cost figure be converted to milliseconds?

No. cost is a unit the planner uses to compare plans with each other, so it has no fixed relationship to time. Actual elapsed time comes from running the statement with ANALYZE and reading the actual time figures.

What does this tool not do?

It does not interpret a pasted plan, recommend indexes or rewrite queries. It only computes misestimate factors from the row counts you enter.