Course contents
On this page
Send partial totals instead of every row
Compute an average across workers without moving the whole table or averaging averages incorrectly.
The shop’s orders are split across two servers. A report asks for the average order value. One correct approach sends every order to a coordinator, which adds the values and divides by the number of orders.
That works, but the network carries all the rows even though the final answer is one number. We have already run operators inside one engine. Now let each worker compute part of the total near its own rows and send a smaller intermediate result. An operation that combines rows into a summary is an aggregation.
Carry enough information to finish the calculation
Assume each order appears on exactly one worker and the workers read the intended consistent input. Ignore null values for this example. Worker A has orders worth 10 and 30. Worker B has one order worth 90.
A computes sum 40 and count 2. B computes sum 90 and count 1. The coordinator adds sums and counts separately, then divides: 130 / 3, approximately 43.33.
Values: 10, 30
Send: sum 40, count 2
Values: 90
Send: sum 90, count 1
Coordinator: (40 + 90) / (2 + 1) = 43.33…
Averaging the two local averages would give (20 + 90) / 2 = 55, which is wrong. That calculation gives the one order on B as much weight as the two orders on A. The transferable state must preserve what the final operation needs.
This is partial aggregation: workers reduce their input, and another operator combines the partial states. Counts and sums combine naturally. Exact medians cannot generally be reconstructed from only each worker’s local median.
Make movement part of the plan
For a large table with one global total, the reduction can be substantial. For a report grouped by customer, each worker may instead send a sum and count per customer. Matching customer groups must meet at the same combining operator.
The transfer between operators is often called an exchange. It consumes network bandwidth, buffer space, and CPU. If one customer has most of the work, that customer’s owner may finish much later than the others. More workers do not automatically divide this uneven work.
A retry must also replace or deduplicate a worker’s contribution. Adding A’s sum twice silently changes the answer. Distributed execution therefore needs task identities and completion rules as well as an arithmetic plan.
Predict the changed report
A has sum 60 across three orders. B has sum 40 across one order. What is the global average?
Combine the states
The total is 100 across four orders, so the average is 25. The local averages are 20 and 40; averaging those would incorrectly produce 30. Counts are part of the answer’s derivation, not optional metadata.
Source and implementation context: CockroachDB’s SQL and distributed execution layer. The numbers above are a standalone worked example.
Extended reference
The extended chapter preserves the original technical coverage, additional examples, and citations. The explanation above supplies the concepts needed for this page; the reference develops the specialist cases.
Find a section from the original chapter
- Learning outcomes
- The network can carry far more intermediate data than answers
- Partition pruning and colocated work
- Broadcast joins
- Repartition joins
- Partial aggregation
- Exchanges, order, and memory
- Stragglers and skew
- Transactions versus analytical priorities
- Compare three join plans with consistent units
- Broadcast requires memory accounting, not just bandwidth
- Partial aggregation carries algebraic state
- Global ordering and top-k need a proof
- Skew can be in data, work, or output
- Exchange backpressure is part of query correctness
- Straggler mitigation should respect resource scarcity
- Trace a complete distributed plan
- Case connection and design conclusion
- Sources and further reading