Pass 2 window composition: tumbling panes

[zzylol]

Rebased on main d4869a7 (DF 54).

Stacked on #599 (wave 1 chain). Part of #580 item A, step 4; #509 Pass 2 window-composition rule.

Why

#509 Example 3, Pattern B, answers a 5-min p99 that runs every minute by merging 1-min tumbling panes. #591 made the executor run that shape, but the planner never generated it. apply_materialization_timings also rejected SummaryMerge, so a pane plan could not be exported.

What

1. Timing. A SummaryMerge runs at its consumer's timing. Its inputs must be summary state, and a merge at ingestion time rejects query-time inputs.
2. Window form as a Pass 1 axis (W3, W4). WindowForm::{Whole, Tumbling { pane_ms }} is set per alternative (LocalLogicalTarget::windows). A query over a range window that repeats on a cadence gets a tumbling copy of every alternative whose family merges (family_merges()), with pane_ms = gcd(lookback, cadence). The cadence comes from RootDemand. A form needs 2 to 64 panes. stage1_logical_candidates now takes demand. Labels read "Q1 Kll · tumbling 1m panes".
3. Realization (W1, W2). Pane i is SummaryAgg over TimeRange(w) over TimeShift(o + i·w) over the one Scan, where o is the query's own offset. Its coverage is derived from that sub-DAG (feat(ir): derive summary coverage as definition + selection #646): relative time (-(o+(i+1)w), -(o+iw)]. A SummaryMerge combines the panes before SummaryEstimate or FinalizeExactAccumulator. Stage 1 uses the form only if the panes' merged coverage equals the whole-window state's, (-(o+lookback), -o]; derivation rejects overlapping panes. The site detection is ported from Generate exact window composition and materialization candidates #566 compose().
4. Stage 3. accuracy_violation looks through a merge and checks each pane build against the family's analytical guarantee. A merge is priced at one operation per input state. Its output is the union of the inputs' groups, bounded the way one build is. This matters: without it, a reader of the merge was priced on one pane's groups, and the DP saw a spurious coupling.
5. DP. In a sharing variant, targets whose panes read one scan are also checked for coupling.
6. Fix. FinalizeExactAccumulator over a SummaryMerge named its value column state, so readers such as a heap sketch over sum_over_time failed to compile. It now looks through the merge.

Before / After

	Before	After
Example 3B candidates	3: exact 2.400, KLL 2.083, DDSketch 2.083 cost/s	5: adds KLL and DDSketch in 1-min tumbling panes, 5.167 cost/s each
Example 3B selected	KLL (2.083)	KLL (2.083)
Example 1 candidates	64	88: Q2's exact sum_over_time also comes in 10-s panes; rates and heaps do not merge
Example 1 selected	P60, 4.620	the same plan, now P82, 4.620; the cheapest tumbling candidate is 9.820
Example 3A	486	486 (one-off batch, so no cadence)

Tumbling costs more for now because everything runs at query time, so every pane is rebuilt at each evaluation. In 3B, the five pane builds together cost the same as the whole build (5 × 0.067 = 0.333). The extra +3.08 comes from each pane's TimeShift and TimeRange passing the full 5-min scan, 20M rows (5 × 0.667 against 0.333), plus 0.083 for the merge. This is left untuned, as asked.

The Example 1 fixture is now 9.3 MB (was 4.1 MB). It has 88 candidates, above the devtool's default display cap of 64, so it is generated with --max-candidates 128. The selection fallback cap stays 64, and the facade's DP (#572) still returns TreeDp on Example 1.

Tests

• Unit tests: the gcd and cadence (including scheduled times); KLL and DDSketch get a form and rate/increase get none; pane construction, shifts and coverage, also with an offset; the coverage proof rejects a width that does not tile; tumbling and whole forms have one output schema (regression for fix 6); SummaryMerge timing (regression for fix 1).
• DP equals exhaustive: Example 1 (88 combinations), and Pattern B with window forms.
• Pass 2 sharing: a 5-min and a 3-min p99 every minute build 8 panes independently and 5 in the shared variant, through the existing identical-expression rule.
• Runtime: the planner's tumbling KLL plan for Pattern B compiles in the executor. Over 2 series × 20 samples it returns the same per-series p99 as the whole-window plan (19 and 119 at ts = 300 000).
• Example 3: ported the test: #509 Examples 2–4 acceptance specs and end-to-end tests #590 tests and planner_layering_common (window_form reads a merged build as a pane). The tumbling-only tests pass. stage3_a_shared_scan_is_not_costlier now passes and is un-ignored. Five tests stay ignored: EH ×2, partial groupings, and sliding windows ×2; the sliding ones name the tumbling test that passes. The spec doc stays in test: #509 Examples 2–4 acceptance specs and end-to-end tests #590.
• stage_pipeline --example planner-layering-3a|3b added (from test: #509 Examples 2–4 acceptance specs and end-to-end tests #590). The Example 1 fixture is regenerated.

Gate: cargo fmt --all --check, cargo clippy --workspace --all-targets --all-features -- -D warnings, cargo test --workspace: 1,609 passed / 12 ignored (#599: 1,580 / 7). Viewer tests: 29 OK.

What Stage 2 materialization needs from this PR

Panes are separate SummaryAgg nodes, each with evaluation-relative coverage, so Stage 2 can assign each one ingestion time (B1) or query time kept (B3) through MaterializationAssignment::set. The merge then follows its consumer. Retention is lookback per pane width. Nothing marks yet which pane is the newest one to build at query time (B3); its coverage [-w, 0) identifies it.

Links: #509, #580, #566 (compose() origin), #591 (executor pane merges), #590 (Example 3 acceptance tests).

🤖 Generated with Claude Code