# Chapter 6: The Waiting Game (Workloads & Locking) In Chapter 3, we met the **[[Postgres/Chapter 3/3.3 - The Soldiers (Scanning & Joining)|Soldiers]]** who execute your queries. We saw them scanning aisles, building jellybean walls, and high-fiving as they joined lists together. On paper, their work looks constant and frenetic. But if you look at the **[[Postgres/Operations/EXPLAIN|Admiral's Battle Report]]** (the `EXPLAIN ANALYZE` output), you will often find a strange discrepancy. The report says the "Execution Time" was 5 seconds, but the soldiers only spent 1 second actually moving suitcases. Where did the other 4 seconds go? ## The Sound of Silence The missing time was spent **waiting**. In the world of Postgres, every soldier has a tiny, invisible stopwatch. Every time they are forced to stop working—whether they’re waiting for an elevator, waiting for a bridge to clear, or waiting for a colleague to stop hogging a suitcase—they click the stopwatch. These recorded pauses are called **[[Postgres/Workloads/_Workloads|Wait Events]]**. Understanding Wait Events is the key to deep database diagnostics. You are no longer asking "What is the elephant doing?" but rather "What is stopping the elephant from doing more?" ## The Battle Report Integration When you analyze a query plan, you are looking at the _logistics_ of the battle. When you analyze Wait Events, you are looking at the _friction_ of the battlefield. - **If the query is slow but the CPU is low**: Your soldiers are likely standing at the **[[Postgres/Chapter 6/6.2 - The IO Elevator (Disk Wait)|IO Elevator]]**, waiting for the basement worker to bring up a Page. - **If the query is slow and the CPU is 100%**: Your soldiers are trapped on the **[[Postgres/Chapter 3/3.3 - The Soldiers (Scanning & Joining)#1. The Matchmakers (Joining)|Hamster Wheel]] (Nested Loop)**, frantically running but going nowhere. - **If the query is stuck but not using any resources**: Your soldiers are likely blocked at the **[[Postgres/Chapter 6/6.3 - The Narrow Bridge (Locks & Latches)|Narrow Bridge]]**, waiting for a Lock to be released. To truly master the engine, you must learn to listen to the silence. What happens when a thousand incredibly lazy, highly opinionated elephants are all crammed into the same room, all trying to read the exact same cheat sheet, or write in the exact same frantic diary, at the exact same moment? They bump into each other. They glare. And worst of all, they have to wait in line. A "Workload" is simply the physiological measurement of the elephant sighing heavily while waiting for its turn. To analyze why your database is slow, you must first determine which of the **Two Modes of Misery** the elephant is currently in: ### 1. The Sweat (CPU Bound) Sometimes, the room is silent because the elephant is thinking so hard his ears are steaming. He is performing a massive [[Postgres/Operations/Sort]], calculating a billion Regular Expressions, or frantically zipping two huge lists together in a [[Postgres/Operations/HashJoin]]. He isn't waiting for anyone else; he is simply at the absolute limit of how fast his brain can work. In this state, you won't see many "Wait Events"—you'll just see a very exhausted, very busy elephant. ### 2. The Sigh (IO Bound) Other times, the elephant is completely still. He is standing by the elevator, tapping his foot, waiting for a [[Postgres/Structures/Page]] to be brought up from the frozen basement ([[Postgres/Resources/Disk IO]]). He cannot continue his work until he has that data in his hand. This is where the "Waiting Game" truly begins. Postgres categorizes every possible reason an elephant might be frozen in place. Sometimes, the blockade is heavy and structural, like a massive iron [[Postgres/Workloads/Lock]] clamped across a table by someone performing an ALTER operation, completely stopping the queue. Other times, the friction is almost microscopic—like thousands of millisecond-long [[Postgres/Workloads/LWLock|LWLocks]] constantly clicking open and shut as elephants politely shove past each other to glance at a shared memory buffer. The database meticulously records exactly why it is paralyzed. Is it suffering from crippling [[Postgres/Workloads/IO|Disk IO]] because the filing cabinet is jammed? Is it sitting idle in a [[Postgres/Workloads/Client]] state, peacefully ignoring the world while it waits for you to send the next command? Is it tangled in complex [[Postgres/Workloads/IPC]] (Inter-Process Communication) as massive parallel workers try to yell messages to each other across the room? By examining these wait events, you can pinpoint exactly which animal in the crowd is refusing to drop their padlock, or if the elevator to the basement is simply too slow for the crowd.