# 3.3 Sargability: The Art of Not Opening Every Box
The most important lesson in database laziness is **Sargability** (Search ARGument ABLE). It is the art of asking a question in a way that allows the elephant to use his shortcuts. The universe demands strict compliance: all queries must be search-argument-able, or you must endure the penalty of a full sequential scan!
## The Librarian's Map (Indexes)
In **[[Chapter 2/2.0 - The Mighty Indexes|Chapter 2]]**, we met the **Index Clerk** and his B-Tree Maps. A **Sargable** query is one where the elephant can just look at the map and point.
When you say `WHERE id = 5`, the Clerk says "Aisle 4, Shelf 2!" and the elephant is done. But when you ask for something "internal"—like `WHERE lower(name) = 'bob'`—the Clerk is suddenly blind. He has a map of names, but he doesn't have a map of *lowercase* names. He has to open every single suitcase, perform a magical transformation on the name, and check if it matches.
## The General's Fog (Query Planning)
Sargability isn't just about speed; it's about **Inference**. The **[[Chapter 3/3.1 - The Lazy General's Map|Lazy General (The Planner)]]** needs to know exactly how much data he’s dealing with before he sends out the troops.
- **Sargable**: The General looks at the map and sees: "Ah, there are exactly 3 Sarabs in Aisle 4." He plans a small, efficient scouting party (**Index Scan**).
- **Non-Sargable**: The General looks at the map and sees... a safe. "I have no idea how many Sarabs have lowercase names," he sighs.
Because he is blind to the **Selectivity** (how many rows match), he has to assume the worst. He orders a full-scale invasion of the entire warehouse (**Sequential Scan**).
## The Join Disaster (Causal Inference)
This "fog" is most dangerous during a **JOIN**. When the General doesn't know how many rows a filter will return, his head starts to spin.
Imagine joining `Users` to `Orders`:
1. If the filter on `Users` is **Sargable**, the General knows only 5 users match. He decides to perform a **Nested Loop**: "I'll take these 5 users and look up their orders one by one."
2. If the filter is **Non-Sargable**, he guesses wrong. "I bet *half* the users match!" he shouts. He decides a **Hash Join** is better, building a massive "Jellybean Wall" (Chapter 6.5) and wasting memory for data that doesn't even exist.
A single non-sargable predicate is like putting a "Safe" on the General's map—it causes a cascade of bad decisions that can ruin the entire battle!
## Common Crimes Against Laziness
| Crime | Why it’s Non-Sargable | The Lazy Alternative |
| :-------------------------------------- | :------------------------------------------------------------ | :--------------------------------------------------------------- |
| `WHERE lower(name) = 'bob'` | The map is for `name`, not `lower(name)`. | Use an expression index or `WHERE name = 'Bob'`. |
| `WHERE date + interval '1 day' > now()` | The elephant has to do math before he can look at the map. | `WHERE date > now() - interval '1 day'`. |
| `WHERE name LIKE '%smith%'` | The Clerk's map is sorted A-Z; he can't find middle bits. | Use a **[[Chapter 2/2.2 - GIN & GiST|GIN Index]]**. |
Remember: if you put a function on the column side of the equals sign, you are putting a safe on the General's map. Don't blindfold your elephant!
---
[[Chapter 3/3.2.3 - The Organizers (Aggregations)|← 3.2.3 - The Organizers (Aggregations)]] | [[Chapter 3/3.0 - The Battle for Efficiency|↑ 3.0 - The Battle for Efficiency]] | [[Chapter 4/4.0 - Safety Without Sweating|4.0 - Safety Without Sweating →]]