What query processing forbids

What this mechanism forbids, and what each escape costs

Forbidden	Escape	Price
Emitting output before a semantically blocking operator has seen its last input	None within the engine. Only changing the question (approximate, incremental, bounded)	The answer is no longer the one that was asked
Knowing anything about data not yet scanned	Runtime filters, sampled adaptivity, mid-flight re-planning	A barrier between pipelines that were independent, plus wasted work when the guess is wrong
Parallelism within a single key	Replicate the other side s ways (salt, skew split, partial broadcast)	s times duplicated work; no escape at all for two-sided skew, where the output is genuinely quadratic
Exact holistic aggregates in bounded mergeable state	Sketches, or sort by (group, value) for positional exactness	Error with no meter, or a sort
Reordering across outer joins and three-valued predicates	None: the constraint is semantic	Plans that cannot be expressed, and rewrites that look valid and are not
Reasoning about a UDF	None inside the engine; the function must be made transparent or declared	Every optimization that depended on purity stops at its boundary
Bounding memory for a final dedup	Sort-based dedup	A sort

Two of these seven have no escape at all. That is unusual: most areas of systems are catalogues of escapes with prices. Here there are genuine walls, and both are logical, not physical. You cannot know the future of a stream, and you cannot reorder around NULL-generating semantics. Everything else is a purchase.

Case, resolvedConstructed case · Omar and Tarini at Shopsy

A plan review checklist

Tarini's one-page plan review checklist for Shopsy analysts:

What does each operator require and provide? Look for sorts, shuffles and hash builds between operators. They are the query.
Is any filter or pre-aggregation placed after a join that could come before it? Cheap, row-shrinking operators first.
Could a NULL change the answer? NOT IN, LEFT JOIN ... WHERE, and counting with NULL keys.
What is the grain after each join? If rows fan out, aggregate at the right grain before the join.
Is any key skewed? Customer 0 (7% of orders) and NULL (2%). A distributed job runs at the speed of its slowest partition.
What is the aggregate's class? Distributive and algebraic: partial aggregation works. Holistic (COUNT DISTINCT, median): expect a hot key to hurt, or use a sketch on purpose.
Estimate rows per group per partition. Near 1: partial aggregation does not help.
Does anything need order, or only grouping? Never pay for a sort if grouping is enough. Do two things need the same order? Make the sort columns share a prefix.
Paging? Use keyset pagination, not large offsets. For ORDER BY ... LIMIT k, expect a heap of size k.
Which way does an approximation's error point? An error that costs work is fine. An error that drops rows is a defect.
Does the query contain a UDF? Expect no optimization across it. Make it transparent or declare it.
Does the number need to be reproducible? Floating-point sums and lossy sketch merges change with cluster shape.

She pins it above Omar's monitor. Omar reads the first line aloud: "What does each operator require and provide?" Then he smiles. "That was my first problem." "And it is the last one," says Tarini. "The rest are that question asked again."