Postgres query planner

Postgres doesn't execute your SQL literally — the query planner analyses the query, consults statistics about each table (row counts, value distributions, correlation between columns), estimates the cost of every possible execution plan, and picks the cheapest. "Cheapest" combines access methods (sequential scan vs index scan vs bitmap scan) and join strategies (nested loop for small inputs, hash join for equality joins, merge join for pre-sorted data). Two practical corollaries: stale statistics lie to the planner — if you load a million rows and immediately query, Postgres may still think the table is empty, so run ANALYZE after bulk loads (VACUUM does this as a side effect); always use EXPLAIN ANALYZE, not EXPLAIN — ANALYZE actually runs the query and shows real timing vs. estimates, which is how you spot a bad plan (estimated 100 rows, got 10 million). The planner is usually smart; when it's wrong, it's almost always a statistics problem.