![[chap_6_resources.png]] # Chapter 6: The Hunger of Resources A lazy elephant is a hungry elephant. While the engine desperately tries to avoid work, the physical reality of resolving your queries requires brutal, tangible resource consumption. In the world of Postgres, resources dictate the hierarchy of effort. [[Memory]] is fast, hot, and cheap—it is the pile of snacks resting conveniently on the elephant's tiny desk. The database will fight viciously to keep its most critical data (Shared Buffers) and operations (work_mem) hovering safely inside memory, because the alternative is horrifying. The alternative is [[Disk IO]]. Disk IO represents the terrifying, frozen filing cabinet across the room. Every time the elephant has to get up, shiver in the cold, and yank open a heavy iron drawer to fetch a page, an immense punishment is enacted against system performance. To understand the scale of this punishment, check the [[_Resources|Resources Overview]]—where a single disk seek is the equivalent of a 4-month-long winter expedition. ![[ex_seek.svg|80]] The entire architecture of the database—from caching algorithms to Bitmap Heap Scans—is designed to violently rip data away from the frozen disk and hoard it onto the warm, messy desk of Memory. When queries become too massive to fit on the desk—exceeding the elephant's strictly defined `work_mem` desk space—the engine is forced to "spill" out, resulting in temporary [[Network]] saturation or panicked spikes in [[CPU]] usage as it frantically attempts to sort gigabytes of data by breaking it apart and gluing it back together in smaller chunks. Understanding the engine is simply understanding how fiercely the elephant guards its snacks.