Governors and runaway kills

When can a query's cost be known before it runs, and when should a cap kill it?

A governor is a mechanism that limits or stops expensive work. It needs, at admission, the one number nobody has (how expensive will this be?), and the ways round that, estimate, observe or price it, are scheduling's. Which one is available is decided by the meter, not by the vendor's generosity.

Under scan pricing, cost is a property of metadata

When billing is per byte scanned, the cost of a query can be computed before it runs. The bytes to be read after pruning follow from manifests and statistics before a single row is touched. This is rare and often overlooked. It makes accurate pre-execution estimation possible, which is why dry-run estimates and hard pre-flight limits exist on scan-metered engines and not on occupancy-metered ones. For example, with Google BigQuery you can ask for the estimate without running the query:

bq query --use_legacy_sql=false --dry_run \
  'SELECT * FROM sales.events WHERE event_date = "2026-10-01"'
# prints: this query will process N bytes when run.

Under occupancy pricing, the cost depends on runtime behavior: spilling to disk, data skew, a join that blows up. It cannot be known in advance. The only options are observation (kill the job at a threshold) and pricing (quotas, slot budgets). The meter decides whether admission control is possible at all.

Under occupancy pricing, then, a governor can only observe and cap. On a heavy-tailed cost distribution a fixed cap captures most of the savings without a model, and it should trip on early evidence, because a kill at 95% pays the full cost and returns nothing (runaway killers). Where the meter allows it, estimate and reject at admission instead.