🧠 Query Planner

How PostgreSQL Decides to Scan, Join, and Sort

Every SQL query goes through the planner/optimizer before execution. PostgreSQL evaluates many possible plans — different scan methods, join orders, join algorithms — and picks the one with the lowest estimated cost. The cost model uses table statistics (row counts, value distributions, correlation) combined with configurable cost parameters to estimate I/O and CPU work. Understanding the planner means understanding why your query is slow — and how to fix it.

🔍 Scan Types: How Rows Are Found

The planner chooses a scan method based on selectivity, table size, and index availability.

Planner chooses:
Index Scan
Low selectivity + index available
📄

Sequential Scan

Reads every page in order. Cheapest for large result sets or small tables. Uses seq_page_cost.

🌳

Index Scan

Traverses B-tree, then fetches heap tuples. Best for very selective queries. Random I/O per row.

Index-Only Scan

All columns in the index — no heap fetch needed (if visibility map says page is all-visible).

🗺️

Bitmap Scan

Builds a bitmap of matching pages, then fetches them in order. Best for medium selectivity.

🔗 Join Strategies

Three join algorithms, each optimal for different data sizes. Drag the sliders to see the planner switch.

Planner chooses:
Hash Join
Best for medium-large unsorted inputs