Repository navigation
Generate different sliding window candidates #556
Description
Activity
Didn't realize. This is already implemented in candidate_gen.rs
Cross-window compatibility requirement from the #554/#557 scoping session:
When a Sliding value aggregation uses a
DeltaSetAggregatorfor key resolution, the DeltaSetAggregator must remain Tumbling-only. Let:W= Sliding valuewindow_size_msS= Sliding valueslide_interval_msD= Tumbling DeltaSetAggregatorwindow_size_ms
The candidate is compatible only when both conditions hold:
D % S == 0— every DeltaSet bucket boundary lies on the Sliding value grid.W % D == 0— DeltaSet buckets exactly partition each Sliding value window.
This relies on both grids sharing the existing Unix-epoch phase/alignment. If either divisibility condition fails (or the phases can differ), candidate generation/validation must reject the pairing loudly rather than allow a query-time partial or misaligned composition.
For Sliding
SetAggregator, the v1 rule remains stricter: it should share the value aggregation’s Sliding window size, slide interval, and grid phase. This exception is specifically for the Tumbling-onlyDeltaSetAggregatorrequired by #588/#606.
Sub-issue of #554.
Scope: the mechanism for producing valid sliding-window
(W, S)candidate combinations for a given query/AQE — the "which window sizes and slide intervals are even legal here" question, separate from actually serving queries against them (#554's other sub-issue).optimizer/candidate_gen.rs'swindow_candidates()(candidate_gen.rs:104-151) already does this conceptually for the offline cost-model/optimizer path (enumerating(WindowType, W_ms, slide_interval_ms, n_windows)tuples with theS | W,S | t_repeat_gcd,S < Wconstraints), but it's only reachable from the offlinecandidate_gen_dump/optimizer_clicost simulators, not from the live planner path.Needs its own design session — not scoped further here. See #554 and the design docs linked there for context.