# 6.4.1 The Sweat (CPU-Bound Workloads) When a detective opens the `pg_stat_activity` window to find the bottleneck and sees... absolutely no stopwatches ticking, it can be disconcerting. If there are no `I/O` waits, no `Locks`, no `LWLocks`, and no `IPC` barriers... then why is the query taking 5 minutes to run? You switch your view outside the database entirely, opening the server's OS monitoring (`htop` or Datadog). Suddenly, you see it: **100% CPU Utilization**. The elephant is not waiting. The elephant is sprinting. ## The Hamster Wheel When the Postgres Cafe enters a **CPU-Bound Workload**, the execution plan is simply asking the Chef to perform an astounding amount of pure mathematics or logical comparisons. The Chef is sweating over the cutting board, swinging the knife as fast as physics permits. Common causes of the Hamster Wheel include: - **Massive Sorts**: Asking the Chef to take 100 million unindexed rows and sort them alphabetically requires massive CPU churn to compare strings (`ORDER BY name`). - **Heavy Joins**: The dreaded **[[Chapter 3/3.2.2 - The Matchmakers (Joins)#Nested Loop Join: The Manual Hand-Off|Nested Loop Join]]** without an index forces the Chef to compare every single row in Table A against every single row in Table B. If both tables have 10,000 rows, the Chef has to do 100 million distinct comparisons. - **Complex Aggregations**: Computing millions of Regex matches, running PostGIS spatial calculations, or deeply parsing JSONB documents (`jsonb_path_query`). The database is doing exactly what you told it to do. It just turns out what you told it to do is exhausting. ## Tuning the Sweat When your Cafe is CPU-bound, your options are entirely different from an I/O or Lock problem: 1. **Change the Receipt (Index)**: The fastest way to sprint a marathon is to teleport to the finish line. If the Chef is sorting 10 million rows, build a B-Tree index so the rows are *already sorted* before the Chef even opens the drawer. 2. **Change the Recipe (Query Rewrite)**: Why is the Chef spinning the Nested Loop hamster wheel? Can you provide an Equality clause (`JOIN ON id = id`) so the Planner can choose a massively more efficient **Hash Join**? 3. **Upgrade the Kitchen (More Hardware)**: If you truly need to parse 5 million JSON documents every second (Analytics/OLAP), you might simply need a processor with more cores and a higher clock speed. > [!info] Diagnostics: The Sweat (CPU) > Is your elephant sprinting but going nowhere? Explore the **[[Workloads/CPU/_CPU|CPU Diagnostic Library]]** to identify internal logic stalls and heavy calculation hotspots. The sign of true Postgres mastery is looking at a 100% CPU spike and knowing immediately whether it is the symptom of a brilliant analytics engine doing its job, or the symptom of a missing index forcing a Chef to read an entire dictionary word by word. --- | ← Previous | ↑ Table of Contents | Next → | | :--- | :---: | ---: | | [[Chapter 6/6.4 - The Weight of the World (Workloads)\|6.4 The Weight of the World (Workloads)]] | [[Learn You a Postgres for Great Good\|Home]] | [[Chapter 6/6.5 - The Kitchen Chaos (Concurrency & Performance Reasoning)\|6.5 The Kitchen Chaos (Concurrency & Performance Reasoning)]] |