Either the data goes to the job or the job goes to the data. Both plans divide by the same link, so the bandwidth cancels and the comparison is code + result against the whole dataset. Since results are almost always far smaller than inputs, one side of that wins by orders of magnitude.
Core ideas
One ratio decides this, and the reason the answer is usually so lopsided is that the ratio is usually tiny.
D/bw against (code + result)/bw. The bandwidth divides both sides, so the comparison reduces to code + result against D — bytes against bytes. A faster link changes how long both plans take and nothing at all about which of them is quicker, which makes this the most portable decision on the course.
The plans tie when code + result = D, and since code is negligible that is when the result is the size of the dataset. Here the result is 5 MB against 2 TB, a ratio of 1/400 000, so moving the compute wins by 384 615×. Aggregations, filters and counts all produce ratios in that region, which is why the answer is so consistent.
Sending SELECT count(*) … instead of the table is exactly this arithmetic, and so is a stored procedure, a map-reduce job, an edge function and a pushdown predicate. Each is a mechanism for shipping a small amount of code to where a large amount of data already is, and each is worth precisely the ratio above.
The material
Where each time comes from, why the link drops out, and the cases in which the usual answer is the wrong one.
For a computation over a dataset of D bytes that emits result bytes, with code bytes of program, across a link of bw bytes a second:
move the data takes D/bw;
move the compute takes (code + result)/bw.
The processing itself is assumed to take the same time wherever it runs, so it appears on both sides and cancels with the bandwidth.
4.44 hours against 41.6 milliseconds is not a close call, and the gap is not a property of this link. Put both plans on a connection a hundred times faster and they become 160 seconds and 0.42 milliseconds — the same factor of 384 615, because both numerators were divided by the same thing.
It is worth doing explicitly, because the conclusion that a faster network does not change the decision is counter-intuitive enough to need the algebra rather than the assertion.
The dataset is 2 TB; the job is a few hundred kilobytes of code; the answer is a single number. Moving the data takes 4.44 hours and moving the compute takes 41.6 milliseconds, and the ratio 1/400 000 is generous — a count returns a few bytes, so the true ratio is nearer 10⁻¹². Every database that pushes a predicate down to the storage layer is making this comparison implicitly.
The comparison inverts exactly when the result is not small. A job that decompresses, joins or enriches can emit more than it reads, and then code + result > D and the data should come to the compute — or, better, the job should be split so that the reducing part runs next to the data and only its output travels.
There are also constraints that are not about time at all. The data may not be allowed to leave its jurisdiction, in which case the compute moves regardless of sizes; or the code may not be allowed to run next to the data, in which case it cannot move whatever the arithmetic says. Both are constraints applied before this calculation, not terms inside it.
The third case is repetition. One transfer of 2 TB followed by a thousand local queries is a different plan from a thousand remote queries, and the comparison to make is D against 1 000 × (code + result). That is still bytes against bytes, with the same cancellation; only the counts changed.
The assumption that the processing takes the same time in both places is the one this model leans on, and it is the one to check. If the data’s home is a storage tier with little processor beside it, moving the compute there may be slower in total even though it moves almost no bytes — and then the right answer is the one the measurement gives rather than the one the ratio suggests.
Interactive
A comparison the link speed drops out of entirely
Method
Three sizes and a comparison. The link is needed only to turn the answer into a duration.
The dataset, the result and the code. Do not start with the link: it cancels, and reaching for it first is what makes people believe a network upgrade could change the answer.
That is the decision, in bytes. Here 5.2 MB against 2 TB, which is not close, and the verdict is stable against anything the network does.
result/D, as a fraction. 1/400 000 here. It is the number that says how safe the verdict is: a ratio near one is a case worth re-examining, and a ratio of 10⁻⁶ is not.
4.44 h and 41.6 ms. These are what a reader remembers, and they are downstream of a decision that was already made, so present them in that order.
Jurisdiction and where code is allowed to run override the arithmetic. Repetition changes which side is multiplied: one big transfer against n small ones is the same comparison with a count in it.
The job is 200 kB of code, the link is a gigabit, and the processing time is taken to be the same wherever it runs.
The order of the two blocks is the method. The decision is taken in bytes, where the link does not appear; the durations are then computed from it, and they are the only place the link is used at all.
The last block is the claim worth defending. A hundredfold faster network divided both numerators by a hundred and left the ratio exactly where it was. Bandwidth buys you a faster winner, never a different one.
For a faded attempt, keep the 2 TB table and make the job emit 1.5 TB — a decompressing scan rather than an aggregation. Predict from code + result against D which side wins before timing anything, compute both durations, and say what result size would have made it a tie.
You should be able to compare code + result with D, show the bandwidth cancelling from the inequality, report the result-to-input ratio as a fraction, and name the result size at which the two plans would tie.
Something to change about this lesson? Write it down, tick it off when it is handled, and export the list when you want to act on it. Kept in this browser only: nothing is sent anywhere, and nobody is notified.
No recommendations yet for this lesson.