# The Query Planner (The Lazy General) When you hand the Lazy Elephant a SQL query—say, `SELECT * FROM users WHERE age > 30`—it doesn't just cheerfully jump out of its chair and immediately sprint to the disk to start wildly rummaging through `Pages`. No. Blindly running into the database to search for things sounds dangerously close to doing hard work. Instead, the elephant sits back in his tent, adjusts his monocle, and summons his most trusted, cynically efficient officer: **The Query Planner**. ## Assessing the Battlefield The Query Planner has exactly one goal: **Calculate the path of maximum laziness.** When it looks at your query, it asks a series of very specific questions to figure out the cheapest way to not have to look at the disk. It consults its `pg_stats` (a tiny little dossier full of gossip it generated about your tables) to see how things are distributed. > "Aha. `WHERE age > 30`. Well, let's look at the stats. Oh, 99% of the users in this table are over 30. If I use my fancy `B-Tree` index to look up every single person over 30, I'll have to bounce back and forth between the Index and the Table a million times. That sounds exhausting." > "Instead, what if I just completely ignore the Index entirely, violently rip the front door off the `users` table, and just speed-read the entire thing from top to bottom?" This is why sometimes Postgres completely ignores that beautiful, expensive Index you built. A [[SeqScan]] is emotionally devastating to watch as an engineer, but to the Query Planner, just reading the whole file in one massive sequential gulp is actually _less work_ than doing millions of tiny, precise index lookups. ## The Cost Equation The Planner doesn't operate on feelings. It operates on a cold, brutal, calculated metric called **Cost**. It assigns arbitrary "effort points" to certain actions: - **`seq_page_cost` = 1.0**: Reading a page of data currently next to the one I just read. This is extremely easy. The disk head is already right there. - **`random_page_cost` = 4.0**: Forcing the disk drive to physically spin its mechanical platters and swing its arm to a completely random new location. The planner hates doing this. - **`cpu_tuple_cost` = 0.01**: Glancing at a single row in memory to see if `age > 30`. This is so easy the elephant barely acknowledges it as work. The Query Planner takes your SQL string and generates potentially dozens of different battle plans (Execution Plans). - _Plan A: Use a Nested Loop Join and a B-Tree Scan._ (Estimated Cost: 45,000) - _Plan B: Hash the whole small table into memory and execute a Hash Join._ (Estimated Cost: 2,500) The Planner compares the costs. Plan B is vastly lazier. Plan B wins. ## The Execution Only after the Planner has absolutely assured itself that there exists no lazier, cheaper, sleazier way to get your data, does the elephant actually stand up. It hands the chosen **Execution Plan** to the Executor, taking the shape of a rigid tree of [[_Postgres Operations]], which march into the database to do the actual heavy lifting.