A job's plan shows few points where records cross the network and even widths, yet the run takes hours — what can the printed text not tell you?

## Shape against quantity Everything a printed plan contains is a statement about **shape**: which steps exist, which needs records from other workers, how the listing divides into runs between those points, how many pieces each step handles at once, and what instruction was handed down to the read. Not one of those is a quantity of data. A job can have a plan you would happily defend in review and still run for hours, and when it does, nothing further can be extracted from the text — you have to go and measure. This matters in an interview because the candidate who cannot say where reading stops will keep re-reading the plan, look for cleverer rewrites, and never reach the thing that was actually wrong. ## What is absent, item by item - **Row counts along each edge.** The plan says a step exists, not how many records reach it. A condition that you assumed removed most of the input may be removing almost none. - **Evenness.** Widths count pieces, never records. Two thousand pieces read the same in the text whether they are equal or whether one holds most of the data — *skew*, where one piece is far heavier than the rest. This is the most common reason a good-looking plan runs badly. - **Bytes moved.** A crossing's presence is printed; its volume is not. One crossing moving a few megabytes and one moving several terabytes look identical. - **Spill.** Whether a step ran out of room and wrote part of its working set to local disk is a run-time event; nothing about the shape predicts it. - **Per-record cost.** A step whose body is ordinary code the rewriter cannot look inside appears as one line. Whether that line costs a microsecond or a network call per record is invisible. - **Duration and pacing.** No step in the printed text carries a time. Nor does the text say how many pieces were queued behind the ones running. - **A slow machine.** One worker running slowly for reasons of its own — a *straggler* — is a property of the cluster that day, and the plan describes no machines at all. ## The read's instruction is not the read's effect This is the subtle one, and it is worth saying explicitly because it looks like an exception. The plan *does* show what the read was told: which columns to produce, and which conditions were pushed down to the point of reading so rejected rows are never produced at all. But that is an instruction. How much is genuinely avoided depends on the source: - a layout that stores columns separately can skip the unrequested ones outright, while a row-oriented or opaque source may have to read and decode the record anyway; - a condition on the attribute the data is physically arranged by can eliminate whole files or whole directories, while the same condition on any other attribute eliminates nothing before decoding; - a source that exposes no filtering interface at all accepts the instruction and returns everything. So "the filter was pushed to the read" is a true reading of the text and a false conclusion about volume. What was skipped is a measurement. ## Where the missing answers actually live | Question | Where it is answered | |---|---| | How many records flowed, how long a step took | Measurements collected while the job ran | | Whether one piece held most of the data | The spread of work across pieces, diagnosed from run measurements | | Whether the run cost is worth changing | Costing a movement, a separate subject with its own rules | | Whether one machine was to blame rather than the data | The slow-worker case, distinguished by whether the same piece is slow on a re-run | One related caution about the text itself: where an engine prints predicted row counts at all, they are predictions made before anything ran. Reading predictions against what really happened is a general execution-plan skill that belongs with database query plans, and it is not a substitute for measuring a distributed job. ## What a senior actually does next 1. **Keep the plan as the map.** It tells you where to point the measurement: at the edges into and out of each crossing, and at the widest steps. 2. **Get per-piece numbers for one step**, and look at the distribution rather than the total. A mean tells you nothing here; the maximum against the median is the whole finding. 3. **Separate data from machine.** If the same piece is slow on a re-run, the data caused it; if a different one is slow each time, the cluster did. 4. **Only then reconsider shape.** If the volumes are as expected and evenly spread and it is still slow, the plan may genuinely be the problem — but that is the last hypothesis, not the first. The short version to say out loud: the printed plan is a route map, and a route map cannot tell you how much traffic is on each road.