references/query-plans.md

# How to read execution plans safely

## Estimated versus actual
Optimizer estimates indicate plan assumptions; actual plans can reveal cardinality gaps and resource bottlenecks. Actual execution may be costly or mutating. In PostgreSQL `EXPLAIN ANALYZE` actually runs the statement; for DML, avoid casual advice to run it against production without transaction and rollback understanding.

## Evidence cues
- Sequential scan/full scan: check volume, predicates, pruning and whether scanning is appropriate.
- Join node: compare input/output rows, skew, nested-loop multiplicity and join condition selectivity.
- Sort/window: memory pressure and spilling.
- MPP shuffle/exchange: distributed movement, network overhead and wrong distribution assumptions.
- Queueing/concurrency: runtime may reflect contention rather than inefficient SQL.

## Platform tools
PostgreSQL `EXPLAIN`; SQL Server actual execution plan and IO/time; Snowflake Query Profile; Databricks Query Profile; BigQuery query plan/execution details; Redshift system views and query analysis; Synapse request step/data movement diagnostics. Prefer engine-specific official manuals and current versions.

Never infer that an index, broadcast hint or warehouse resize is automatically best without objective plan and workload evidence.