A job spends most of its time in a step whose body the engine cannot read. Which structural changes reduce that cost without rewriting the body?

## Why the author has to do this An **opaque step** is a step whose body is ordinary code the **plan rewriter** — the engine component that edits the declared graph into an equivalent, cheaper graph before running it — cannot look inside, so it can only be called, never reasoned about. Every rewrite that would have narrowed the work around that step needed a fact the body does not supply: which fields it reads, whether skipping a call is safe, what it costs. The engine therefore does the only safe thing and runs the graph as written. That is the whole reason this is an author's job. Nothing here is clever; it is supplying by hand the facts the engine could not deduce. ## The four moves, in order 1. **Put the narrowing before the step.** Apply the conditions and select the fields *above the read and below the body*, in the graph as written. The step then sees fewer records and smaller ones. This is the move with the largest payoff on a wide input and the one candidates most often skip, because they are waiting for the engine to do it. 2. **Hand the body named fields, not the whole record.** The argument list is the only visibility the rewriter has. Naming two fields instead of passing a record restores read-time column narrowing — the rewrite that tells the read to produce only the columns some later step uses — for everything the body does not name. 3. **Split the body.** Most author-written bodies are a small custom core wrapped in work the engine already understands: a comparison, an arithmetic expression, a null check, a string operation. Express those as named operators and only the core stays unreadable. What moved out becomes reorderable, narrowable, and collapsible into a single pass over each record with its neighbours. 4. **Change the call count.** The body is called once per record arriving at its position, so move the position. Calling it after a grouping, after a deduplication of distinct inputs, or on one row per key instead of every row can cut calls by orders of magnitude. This is only valid where the semantics allow it — a body that must see every record cannot be moved above a reduction — and it is the move most likely to change results if applied carelessly. Only after those is *making the body faster* the right lever, and it is the most expensive one: it means changing code somebody owns and tests. ## How to tell which one you need | symptom | likely move | |---|---| | the read produces every column although the job outputs four | move 2, then move 1 | | the call count is close to the input row count and the output is tiny | move 1, then move 4 | | the body is twenty lines of which three are custom | move 3 | | the body is cheap but the step still dominates the time | the cost is the hand-off to another runtime, not the body | | the step's time is proportional to what the body genuinely computes | rewrite the body, or accept the cost | Reading those facts off the engine's own rendering of what it intends to run is a skill of its own, owned by Reading a Job Plan; the point here is which restructuring each fact argues for. ## Two claims that do not travel Be careful with two statements that are true of one engine model and false of another. - **"The engine would have done this for me"** — only on an engine with a rewriter over a declared-operator surface, and only for steps it can read. In the model that runs one grouping step at a time and writes every intermediate to disk before the next begins, essentially nothing is rewritten for anybody, and all four moves were always the author's job. - **"Fewer calls is always safe"** — moving a body above or below a grouping changes what it sees, and if it is not deterministic or has effects outside the job, it changes the outcome too. The engine refused this rewrite for exactly that reason; taking it yourself means taking responsibility for the proof. ## What an interviewer is checking That the candidate treats the unreadable body as a *position in a graph* rather than as a piece of code. The fastest available win almost never involves opening the body: it involves changing what reaches it and how often. A candidate who jumps straight to rewriting the body has not understood why the step was expensive — and one who says "I would let the optimiser handle it" has just told you they do not know what an unreadable body does to an optimiser.