Repository navigation
Conversation
5 tasks done
zzylol
force-pushed
the
stack/windows-1-b3
branch
from
October 5, 2026 03:07
5540b73 to
9a2a154
Compare
zzylol
changed the base branch from
stack/509-viewer-stages
to
stack/satisfies-error-metric
October 5, 2026 03:08
This was referenced Oct 5, 2026
zzylol
force-pushed
the
stack/windows-1-b3
branch
from
October 5, 2026 06:21
9a2a154 to
aa2ddc0
Compare
This was referenced Oct 5, 2026
Closed
zzylol
force-pushed
the
stack/satisfies-error-metric
branch
from
October 8, 2026 16:47
4f65ff1 to
e30d21a
Compare
zzylol
force-pushed
the
stack/windows-1-b3
branch
from
October 8, 2026 16:47
aa2ddc0 to
cfafcf1
Compare
zzylol
force-pushed
the
stack/satisfies-error-metric
branch
from
October 10, 2026 14:32
e30d21a to
ee6df66
Compare
zzylol
force-pushed
the
stack/windows-1-b3
branch
from
October 10, 2026 14:32
cfafcf1 to
cd7ba50
Compare
Stage 2 now offers a third materialization for the tumbling panes of a query repeating every pane width: built at query time and kept across evaluations. Each evaluation builds the newest pane from one pane width of raw data, merges it with the N - 1 kept panes, then keeps it and drops the oldest (Q59). The physical node carries a `kept` flag (omitted when false), set by Stage 2 and exported in the PhysicalASAPDAG. Stage 3 prices a kept chain like an ingestion-time one but at query time: the newest pane's build per evaluation, (N - 1) panes retained at cost_per_retained_byte_second and counted against the memory budget, and a scan (and raw retention) of one pane width. A deployment without query_time_retention, such as the reference executor, rejects the candidate with a reason (Q56, Q57). The viewer shows "query time, kept" in a kept node's timing. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W7qG9aFyPij5uWsyAJCxDW
zzylol
force-pushed
the
stack/windows-1-b3
branch
from
October 11, 2026 17:11
cd7ba50 to
bdde9b5
Compare
zzylol
added a commit
that referenced
this pull request
Oct 13, 2026
The specs and tests from #590 run the current stages through the shared planner_layering_common pipeline (Pass 1 and composition, optimize_physical_asap, select_plan); tests are named after the stages. Materialization is read from the physical DAG (#667); window forms and retention stay pending adapters. Behavior that works passes (29 tests); every expectation that needs a feature not in this stack is ignored with the PR that delivers it (29 tests): Pass 2 sharing (#588, #595, #596), window composition (#601, #628, #634), materialization enumeration and MatAtQuery (#604, #625), UnivMon sizing and accuracy (#621), SQL recognition and COUNT(*) composition (#598, #603) and plan selection row estimates (#632). Each spec's "Today" column states the current output. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W7qG9aFyPij5uWsyAJCxDW
3 tasks
zzylol
added a commit
that referenced
this pull request
Oct 13, 2026
The specs and tests from #590 run the current stages through the shared planner_layering_common pipeline (Pass 1 and composition, optimize_physical_asap, select_plan); tests are named after the stages. Materialization is read from the physical DAG (#667); window forms and retention stay pending adapters. Behavior that works passes (29 tests); every expectation that needs a feature not in this stack is ignored with the PR that delivers it (29 tests): Pass 2 sharing (#588, #595, #596), window composition (#601, #628, #634), materialization enumeration and MatAtQuery (#604, #625), UnivMon sizing and accuracy (#621), SQL recognition and COUNT(*) composition (#598, #603) and plan selection row estimates (#632). Each spec's "Today" column states the current output. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W7qG9aFyPij5uWsyAJCxDW
zzylol
added a commit
that referenced
this pull request
Oct 13, 2026
…stages (#577) * test: acceptance spec and pending tests for planner-layering Example 1 Define MVP acceptance for #509 Example 1 before the Phase C stage APIs exist: 1 -> 6 -> 6 -> 1 candidates (Pass 1 x identical-expression sharing; physical operator implementation only, no materialization). - Spec with per-stage candidate tables, invariants and doc ambiguities. - Integration tests against todo!() stage stubs, ignored until the stages land; workload and Stage 0 frontend-shape tests run now. - Expected-only asap-stage-pipeline/v1 fixture for the DAG viewer. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * test: run the Example 1 acceptance tests against the real stages Replace the todo!() stubs with adapters over Stage 0-3, un-ignore the 11 tests that pass, and give each still-ignored test the precise difference between the implementation and the spec. Add runtime capability checks: the selected plan compiles in the physical planner; compiling every candidate stays ignored with the two runtime gaps it finds. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * test: read Example 1 logical stages as flat DAGs after the export removal Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W7qG9aFyPij5uWsyAJCxDW * test: Example 1 acceptance on the composed stages (1 -> 3 -> 3 -> 1) The tests run Pass 1 and composition, optimize_physical_asap and select_plan through a shared tests/planner_layering_common pipeline, and follow the decided behavior: three Pass 1 candidates (Q2 exact, CMS+heap, CountSketch+heap), every sub-DAG NotMaterialized, P1 selected, CMS+heap invalid (weights not proven non-negative) and CountSketch+heap invalid (a Top-K output has no guarantee and no deployment evidence). Hydra (#605), Pass 2 sharing (#588) and the two runtime gaps (#593, #579) stay ignored with the PR that delivers them. Tests are named after the stages; the compile check no longer uses the PromQL fallback. The spec lists where the doc and the planner differ. The expected-only viewer fixture is removed: the generated four-stage fixture replaces it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W7qG9aFyPij5uWsyAJCxDW * test: port #590's Example 2-4 acceptance specs and tests The specs and tests from #590 run the current stages through the shared planner_layering_common pipeline (Pass 1 and composition, optimize_physical_asap, select_plan); tests are named after the stages. Materialization is read from the physical DAG (#667); window forms and retention stay pending adapters. Behavior that works passes (29 tests); every expectation that needs a feature not in this stack is ignored with the PR that delivers it (29 tests): Pass 2 sharing (#588, #595, #596), window composition (#601, #628, #634), materialization enumeration and MatAtQuery (#604, #625), UnivMon sizing and accuracy (#621), SQL recognition and COUNT(*) composition (#598, #603) and plan selection row estimates (#632). Each spec's "Today" column states the current output. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W7qG9aFyPij5uWsyAJCxDW * feat(devtools): stage_pipeline examples for #509 Example 3 Ported from #590: --example planner-layering-3a (Pattern A, ad hoc batch of five p99 reports) and planner-layering-3b (Pattern B, repeating 5-min p99), the Example 3 acceptance tests' workloads. Example 1's output is unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W7qG9aFyPij5uWsyAJCxDW * test: follow #576's per-consumer charging and exact top-k columns Plan selection charges a NotMaterialized node once per consuming query, so the charging helper checks NodeCost.multiplier and the Example 4 A3 ambiguity is recorded as decided. Example 1 checks that exact Q2 sorts by the ranked value and returns [job, topk_10]. The stage viewer guide's tab 1 row now describes the actual all-exact result. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W7qG9aFyPij5uWsyAJCxDW * refactor(devtools): one planning pipeline for stage_pipeline and the acceptance tests run_planning_stages and the #509 example workloads move into the asap-devtools library; stage_pipeline serializes the run and the planner-layering tests adapt it. The shared data workload drops ingestion_rate for data at rest, which validate() requires. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W7qG9aFyPij5uWsyAJCxDW * fix(devtools): select over every candidate; --max-displayed limits only the document stage_pipeline capped enumeration at 64, so Example 3a (243 candidates) selected P41 instead of the cheapest P122 (KLL for all five queries). The pipeline now enumerates, optimizes and prices every candidate; the document shows the first --max-displayed (default 64) plus the selected one, with `combinations` and `capped`. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W7qG9aFyPij5uWsyAJCxDW * docs: Example 2's SQL candidates compose; the SQL test waits only on #598 Running the ignored SQL test composes every candidate and fails only on Q2's options (per-source counts until #598), so #603 is not a blocker. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W7qG9aFyPij5uWsyAJCxDW * test: name stages by number and name; say query-language frontends The frontends' Run field, id and locals become stage0_query_language_frontends, and test names carry stage0..stage3 with the stage name. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W7qG9aFyPij5uWsyAJCxDW * test: charging helper follows plan selection's per-consumer rule With a materialized node the helper accepted any multiplier >= 1. It now computes each node's computations as plan selection does (walks from query roots and materialized nodes' inputs, stopping at materialized nodes), checked on a hand-built candidate with a materialized node. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W7qG9aFyPij5uWsyAJCxDW * test: Example 1 picks Q2 candidates by (option, no shared input) physical_with and the invalid-candidate check no longer assume one candidate per Q2 option, so #588's shared-input variants need no change. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W7qG9aFyPij5uWsyAJCxDW * docs: Example 3 Pattern B charges each node once per consuming query Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W7qG9aFyPij5uWsyAJCxDW * docs(stage-viewer): rows 2, 3a and 3b describe the planner's current output Read from uncapped runs: Example 2's sketch plans are rejected for having no (ε, δ) guarantee, 3a selects P122 (first of 108 tied cheapest plans, nothing shared yet) and 3b selects query-time KLL; panes and the latency check come with the window-summary PRs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W7qG9aFyPij5uWsyAJCxDW * docs(stage-viewer): row 2 from the SQL run; 3a ties 32 plans, not 108 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W7qG9aFyPij5uWsyAJCxDW * test: Example 1 counts only unshared candidates; stage3_ charging-helper names The 3-logical and 3-physical counts now hold when #588 adds shared-input variants. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W7qG9aFyPij5uWsyAJCxDW * refactor(devtools): PlanningStagesRun fields carry stage number and name Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W7qG9aFyPij5uWsyAJCxDW * test(devtools): unique temp file per stage_pipeline run cargo test runs the tests as threads of one process, so two runs of the same example shared a file name and one deleted the other's output. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W7qG9aFyPij5uWsyAJCxDW --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stack: #574 → #620 → #618 → #621 → #627 → #625 → #628 → #632 → #634 → #616 → #617 → #622 → #624 → #629 → #630 → #631 → #633 → #635 → #636 → #637
Problem
Stage 2 offered a repeating query's tumbling panes only two ways: rebuilt at query time at every evaluation (B2) or maintained at ingestion time (B1). Example 4's third option, B3 (query time, kept), was missing, so
stage2_b_tumbling_kll_has_three_materialization_optionsandstage2_b_b3_keeps_query_time_windowswere ignored, and Stage 3 never priced it.Changes
Decisions Q56–Q59, Q63.
PhysicalASAPDAGNodegainskept: bool: a query-time output kept across evaluations. It is serialized only when true, so documents without kept nodes are unchanged; the wire version stays 8.ExecutionTimingstays two-valued (Q58).MaterializationAssignmentcarries the kept set, andsplit_shared_by_phaserekeys it.MaterializationSpacenow gives each unit a three-way choice: not materialized, ingestion time, or kept (Choice,Choices). Only tumbling panes can be kept, and only when every root reaching them repeats at a fixed interval equal to the pane width, so each evaluation builds exactly one new pane. Keeping needs neither arriving data nor predictability.down_closed_setsstill keeps the ingestion-time units down-closed, and kept units are unconstrained. It returnsNoneaboveMAX_PHYSICAL_PER_LOGICAL(16): the greedy search then also tries "kept" moves. With 5 independent pane chains that is 3^5 = 243 choices, which are searched greedily. Labels read e.g.query time, kept: Kll ×5 panes.capability_violationrejects any candidate with a kept node whenquery_time_retentionis false, with the reasondeployment cannot keep query-time state across evaluations (query time, kept)(Q57). The executor staysquery_time_retention: false(Q56).pane_rolesalso covers kept chains. The newest pane is built per evaluation at the evaluation rate, and it retains(N − 1) · groups · state_bytesbytes atcost_per_retained_byte_second, counted against the memory budget. The older panes and their shifts and ranges cost 0. Throughscan_extent_ms, both the scan and the raw retention cover one pane widthw(Q59). Per-evaluation work, which also feeds the latency check, is the newest pane plus the merge and the estimate.stage3-cost-model.mdmoves B3 from out of scope into the memory term and deployment checks. Cold start is not priced.⏱ query time, kept, in both the node label and the details panel.query time, kept: exact Sum ×6 panesplan, which takes it from 112 to 136 physical plans. The executor rejects all of them on capability, so the selection is unchanged: P82, 4.620/s. The fixture's--max-candidatesgoes from 128 to 160, so every plan is still written.Tests
stage2_b_tumbling_kll_has_three_materialization_optionsandstage2_b_b3_keeps_query_time_windows(Example 4). The second now also checks that the five panes are kept.stage2_b_tumbling_kll_has_b1_and_b2, by the three-option test.stage3_b_executor_rejects_b3: rejected on the executor's capabilities, with the reason.stage3_b_kept_panes_win_when_the_deployment_can_keep_them: 4b-like, 1k series sampled every 7.5 s, 1 h window every 10 min, raw data not kept,query_time_retention: true. B3 is priced, cheaper than B1 and B2, and selected.kept_panes_build_the_newest_and_retain_the_others: a Stage 3 unit test of the price and the rejection.kept_panes_need_one_new_pane_per_evaluation: a Stage 2 unit test.test_kept_nodes_say_so_in_their_timing: a viewer test.stage2_b_sliding_kll_has_two_materialization_options(Example 4): the three-option tumbling test covers it.stage1_b_window_composition_adds_sliding_and_tumbling_per_option(Example 3): covered bystage1_b_window_composition_adds_tumbling_per_option.stage1_b_merge_only_where_the_window_form_needs_it(Example 3): covered bystage1_b_tumbling_merges_five_panes_before_the_estimate.WindowForm::Slidingvariant, and the sliding arm ofstage1_b_window_parameters_are_legal.materializationreads the exportedkeptflag (QueryTimeKept).retention_msgivesN · wfor a kept pane.stage3_b_tumbling_candidates_are_valid, and plan-selection. Example 1's runtime and capability checks treat kept plans as rejected on capability.Test plan
cargo fmt --all --checkcargo clippy --workspace --all-targets -- -D warningscargo test --workspace: 1684 passed, 0 failed, 16 ignored (re-run after the rebase on main d4869a7)python3 -m unittest test_viewer(tools/dag-viewer): 25 OK--max-candidates 160. Its selection is unchanged.🤖 Generated with Claude Code