Two engines divide a worker's budget differently - one shared pool, one reserved block. What does each design buy and cost?

## Why this question exists at all A **worker** - one operating-system process running some of the job's work, owning memory nothing else can borrow - has to decide, before any record arrives, how much of its budget may go to operators that are running and how much to results the job asked it to hold. Engines of this class answer differently, and the difference is not cosmetic: it changes what runs out first, what the failure looks like, and whether a number that worked on one engine means anything on another. ## Design one: a single pool divided at runtime The engine keeps one accounted pool and assigns it dynamically between two uses: - **Operator working memory** - room borrowed while a step runs, for sorting, for the in-memory table an aggregation builds with one entry per distinct key, for the built side of a join, and returned when the step ends. - **Retained-result memory** - room holding intermediates the job pinned so later steps read them instead of recomputing the branch above. Because the line moves, room that one use does not need is available to the other. What you buy is utilisation. What you pay is coupling: a pinned result can be dropped under pressure from running operators, and a job with a lot pinned leaves operators working against less room than the headline budget suggests. Two runs of the same program can therefore behave differently depending on what was pinned when. ## Design two: a fixed block the engine manages itself The engine reserves a block up front and manages it as **engine-managed binary records** - a packed byte layout it allocates and interprets itself, so a field is read at a known offset rather than by following a pointer to an object. Everything else in the process - ordinary language objects, buffers, user-supplied code - lives outside that block, under the host language runtime. What you buy is predictability. The block does not shrink because something else grew; an operator that exceeds it behaves deterministically, typically by **spilling** - writing part of its working set out to disk attached to the worker and reading it back to finish the step; and the packed layout largely avoids **automatic reclamation** inside the block, the runtime's periodic sweep for objects nothing refers to any more, which stops the worker's own work for as long as it takes. What you pay is stranding and arithmetic: a block sized for the heaviest operator is idle when that operator is not running, and the rest of the process now needs sizing of its own. ## Design three: hardly any of the above The oldest shape in this class - a two-phase disk-to-disk model - has almost no notion of a kept result. Each unit of work gets a working buffer of fixed size, fills it, sorts and writes it out, and the memory story is essentially *how big is the buffer and how often does it spill*. Any question phrased as *how does the engine balance kept results against operator work* is unanswerable on it, which is exactly why this subject is stated as a disagreement rather than as one layout. ## Side by side | | shared pool, divided at runtime | fixed reserved block | |---|---|---| | unused room | goes to the other use | stays reserved and idle | | predictability | lower: depends what is pinned | higher: the boundary does not move | | a kept result under pressure | may be dropped to free operators | competes outside the block, if it exists at all | | reclamation pauses | felt across the whole pool | largely avoided inside the block | | what you must size | one number, plus the uncounted region | two numbers, plus the uncounted region | ## What follows for an engineer 1. **Never carry a memory recipe across engines.** A fraction, a ratio or a rule of thumb encodes where one engine's line falls. On an engine that draws it elsewhere the same numbers move pressure to a different place, usually the one you were not watching. 2. **Say which boundary you mean.** The region boundary an operator spills at is crossed routinely and is not a failure. The ceiling the platform applies to the whole process is fatal. They are different lines and only one of them is the engine's. 3. **Expect a different failure signature.** On a shared pool, memory trouble often shows as kept results disappearing and branches being recomputed. On a reserved block, it shows as an operator spilling at a boundary while the rest of the process looks comfortable - or the reverse, the process running short while the block sits half used. ## The sentence to avoid *The engine splits its memory between execution and storage.* It is true of one lineage and false of the others, and it is the most common way this subject is taught wrongly. State it as *some engines divide one pool at runtime, others reserve a fixed block and leave the rest to the host runtime, and one older model barely holds results at all* - then say which you are on.