Runaway killers and result governors
When should a query be killed, and on what evidence?
This is what a system does when it cannot estimate: it stops predicting and starts truncating. A query's cost distribution is heavy-tailed: a small fraction of queries consume most of the resource. So the mean is set by the tail, and a hard cap moves the mean far more than any tuning of the median case. The cap does not need to be accurate. It only needs to be finite.
The catch: the cost of killing late
Killing a query destroys sunk work, and the expected loss grows with how long you wait. Killing at 95% of completion is the worst outcome available: maximum cost, zero result. That argues the limit should trip on something visible early:
- estimated bytes scanned,
- cardinality (number of rows) after the first stage,
- memory growth rate,
rather than on elapsed time, which correlates with sunk cost by construction. Most implementations use elapsed time, because it is the only thing that is always measurable, and they pay for it.
Result governors
Result-set governors are a different mechanism wearing similar clothes. They protect the client and the network link, not the cluster. The failure they prevent is a driver running out of memory from an unbounded fetch (a client pulling a billion rows).
When you cannot predict a cost you cap it, and the cap should trip on early evidence rather than on elapsed time.