Query Plan

The planner chooses between access methods (sequential scan, index scan, index-only scan), join strategies (nested loop, hash join, merge join) and orderings, using table statistics to estimate how many rows each step will produce.

What to read for, in order:

Estimated versus actual rows. A large divergence means the statistics are stale and the planner is choosing badly on bad information. The fix is often ANALYZE, not a new index — the cheapest possible remedy and the most commonly missed.

Sequential scan on a large table where a selective predicate exists. Either the index is missing, or something in the query prevents its use — a function applied to the indexed column, a type mismatch, or a leading wildcard.

Nested loop over a large outer relation, which is quadratic and usually means the planner underestimated the row count.

Sorts or hashes spilling to disk, which indicates insufficient working memory for the query.

Always use the form that executes the query and reports actual timings (EXPLAIN ANALYZE), not the estimate-only form, and run it against production-like data volume — a plan derived from a thousand rows tells you nothing about ten million.