PostgreSQL EXPLAIN guide
Nested Loop in PostgreSQL EXPLAIN
Nested Loop is excellent when the outer side is small and the inner lookup is cheap. It becomes dangerous when an underestimated outer relation causes an expensive inner operation to repeat thousands of times.
Example EXPLAIN output
Nested Loop
Actual Rows: 48,391
-> Index Scan on customers
-> Index Scan on orders
Actual Loops: 48,391What PostgreSQL is telling you
The inner branch executes once per outer row or loop.
Actual Loops exposes how many repetitions occurred.
Timing and row estimates reveal whether repetition was expected.
What it can mean
A cheap inner lookup repeated many times may dominate runtime.
Bad cardinality estimates often contribute to unexpected loop amplification.
The node type alone is not evidence of a bad plan.
What to check next
Actual Loops on the inner node.
Rows produced by the outer node.
Index access on the inner relation.
Plan Rows vs Actual Rows before the join.
Join predicates and data distribution.
When this is not automatically a problem
- • Small outer inputs with indexed inner lookups are ideal use cases.
- • Nested loops can beat hash joins for highly selective queries.
- • Focus on measured time, not the node name.
Check your actual plan
PlanCheck analyzes TEXT or JSON locally in your browser. Your SQL and plans are not uploaded.
Analyze EXPLAIN output