From 8d21eb8c34f4ba30eee563f1467b91751d3792c9 Mon Sep 17 00:00:00 2001 From: zz_y Date: Sat, 22 Aug 2026 18:50:48 -0600 Subject: [PATCH 1/5] docs(asap-aware-mapping): flesh out ReplacementStrategy/search design, link issue #33 sub-issues MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit docs/asap_aware_mapping.md already stubbed TargetSubDAG/ReplacementSubDAG/ ReplacementStrategy/CostModel and a Volcano/Cascades-style search pseudocode as "not yet implemented" (since #206/#211). This turns that stub into an actionable design and ties each piece to a tracked sub-issue of #33: - #251: generalize today's single-pick decisions (boundary::implementation_for, cse::share_common_subtrees) into real ReplacementStrategy impls that report every valid candidate instead of collapsing to one. - #252: the Cascades/Volcano-style search engine itself — MEMO-based candidate plan space (not a flat plan list), deduped via pre_asap::cse's existing structural-hash/InternTable machinery, sorted by CostModel. Explicitly reconciled against docs/cse-cost-model-decision.md (#237), which scoped a narrower binary share/don't-share decision away from full search infrastructure — #252 is the multi-axis case that decision itself flagged as the reason a real engine would eventually be needed. - #253: semantic-equivalent rewriting (avg -> sum/count) as a ReplacementStrategy, no longer needing its own bespoke before/after-CSE heuristic once a real search exists to let both forms compete on cost directly. - #254: group-by-lattice roll-up reuse (AHA vs. independent per-subpopulation treatment) as a ReplacementStrategy, gated on agg_is_mergeable and Schema::unique_keys the same way CSE's own legality gate is. - #256: GroupingStrategy::{PerSubpopulationInstance, SharedMultiSubpopulation} (Hydra) as a new axis orthogonal to SketchKind/SamplingKind/..., named for sharing across a query's own subpopulations (not multi-tenant deployment isolation). - #257: rebuild applicability.rs (#247) as a view over the search's candidate space instead of a parallel tree-walking system. Also resolves the doc's stale "(TODO: is this implemented?)" on parameter sizing — boundary::implementation_for's bind_summary_with already sizes every candidate via CostModel::size_params. No code change. Co-Authored-By: Claude Sonnet 5 --- docs/asap_aware_mapping.md | 44 +++++++++++++++++++++++++++----------- 1 file changed, 32 insertions(+), 12 deletions(-) diff --git a/docs/asap_aware_mapping.md b/docs/asap_aware_mapping.md index 0c270c31..1440598d 100644 --- a/docs/asap_aware_mapping.md +++ b/docs/asap_aware_mapping.md @@ -3,17 +3,23 @@ ASAP-aware mapping decides **whether and how an intent can be answered by a summary** rather than by scanning raw data. The input is a pre-ASAP plan and the output is a set of candidate post-ASAP plans. This layer decides what kind of sketches can be used to satisfy a query. -Based on any given accuracy targets, it can also assign parameters to those sketches. (TODO: is this implemented?) +Based on any given accuracy targets, it can also assign parameters to those sketches (implemented today — `boundary::implementation_for`'s `bind_summary_with` sizes each candidate via `CostModel::size_params`; see `default_size_params`'s per-family formulas). This layer **does not** assign physical resources like CPU and memory to nodes in the plan. -## Key concepts (not yet implemented) +This document tracks issue #33 ("add logic to detect which optimizations/summaries are applicable to a query workload"); the sub-issues cited below are where each piece below is actually being implemented. + +## Key concepts - TargetSubDAG: Pre-ASAP sub-DAG that is a candidate to be replaced by a post-ASAP sub-DAG - ReplacementSubDAG: Candidate post-ASAP sub-DAG to replace a pre-ASAP sub-DAG -- ReplacementStrategy: Each stratey defines one TargetSubDAG and one or more ReplacementSubDAGs +- ReplacementStrategy: Each strategy defines one TargetSubDAG match and every valid ReplacementSubDAG for it (not ranked, not filtered — every strategy's job is to be exhaustive, not to decide) - CostModel: Estimates the cost of a post-ASAP plan. Can be based on heuristics or empirical estimates -## Pseudocode for Replacement Plan Searching (not yet implemented) +Tracked as **#251**: today, the two decisions this crate already owns — `boundary::implementation_for` (which summary family/kind realizes an `AggIntent`) and `cse::share_common_subtrees` (which subtrees can be shared) — each collapse straight to one answer instead of exposing themselves as a `ReplacementStrategy` with a candidate list. #251 generalizes both into the trait above, as the first two real `impl ReplacementStrategy`s (no new decision procedure, same discipline `applicability.rs` (#247) already used for these two). + +## Replacement plan search + +Tracked as **#252**, implementing the pseudocode below for real: ``` input_replacement_strategies: List[ReplacementStrategy] @@ -37,6 +43,12 @@ output: candidate_plans ``` +Two things #252 has to get right that this pseudocode leaves open: + +- **Dedup** must be structural-hash-based, reusing `pre_asap::cse`'s existing `InternTable`/`structural_hash` machinery (hash as a filter, `PartialEq` as the real decision) — not `Vec` containment over whole serialized plans. +- **MEMO-style sharing across candidate plans, not a flat plan list** — a naive flat list of whole candidate plans duplicates every untouched subtree across every candidate (a workload with N independently-choosable sites produces up to 2^N flat plans). Each distinct `TargetSubDAG` becomes a MEMO group holding its alternative `ReplacementSubDAG`s, so two candidate plans differing at one site still share every other node by `Rc`, the same way `share_common_subtrees` already shares identical subtrees today. + +This is a genuine change of scope from `docs/cse-cost-model-decision.md` (issue #237), which deliberately chose a direct cost comparison over "full Volcano/Cascades-scale infrastructure" for *one* binary, single-candidate-pair decision (share a CSE'd subtree or don't) — reasoning at the time that "this repo has no plan-enumeration/DP-search engine anywhere" and didn't need one for that narrow question. #252 is where that stops being true, for the reason #237 itself named: once multiple interacting axes exist at once (sketch family/kind, roll-up vs. recompute, Hydra vs. per-subpopulation, semantic rewrite), a per-decision-point heuristic can't see interactions across sites the way a real candidate-plan search can. `CostModel::cse_share_decision`'s existing recompute-vs-maintenance comparison isn't thrown away — it becomes the cost function backing the CSE `ReplacementStrategy`'s two candidates (share vs. recompute-independently) inside this engine, so the final `sorted_by(cost_model)` step reuses it rather than re-solving the same comparison a second way. ## Summary mapping @@ -74,17 +86,25 @@ Cost / accuracy / latency constraints chosen implementation ``` -## Degrees of freedom we should explore (not yet implemented) +## Degrees of freedom we should explore Selecting a sketch: -- Different sketches (KLL vs DDSketch) +- Different sketches (KLL vs DDSketch) — today only *ranked* (`CostModel::rank_candidates` takes the head); exposed as real alternative candidates once #251 lands - Different parameters for same sketch -- Hydra vs sketch-per-subpopulation (exact treatment of subpopulations) -- Single-level Hydra (what the paper talks about) or multi-level Hydra (e.g. CMS on top of CMS on top of CMS) -- Sliding window vs tumbling window computation (this is specific to ASAPCollector and ASAPQuery's precompute engine) -- Sliding window sketches (e.g. Promsketch) vs exact treatment of time -- AHA vs treating hierarchical subpopulations independently -- Combining computation between part from the sketch, and part from the raw data to meet an accuracy target +- Hydra vs sketch-per-subpopulation (exact treatment of subpopulations) — tracked as **#256**: a new axis orthogonal to `SketchKind`/`SamplingKind`/…, `GroupingStrategy::{PerSubpopulationInstance, SharedMultiSubpopulation}` (named for sharing across a query's own subpopulations, not multi-tenant in the deployment-isolation sense), with `HydraKind`/`HydraParams` mirroring the existing per-family `(Kind, Params)` pattern +- Single-level Hydra (what the paper talks about) or multi-level Hydra (e.g. CMS on top of CMS on top of CMS) — not yet tracked; a refinement of #256's `HydraParams` once single-level lands +- Sliding window vs tumbling window computation (this is specific to ASAPCollector and ASAPQuery's precompute engine) — not yet tracked here +- Sliding window sketches (e.g. Promsketch) vs exact treatment of time — not yet tracked here +- AHA vs treating hierarchical subpopulations independently — tracked as **#254**: two `Aggregate` nodes over the same shared source with mergeable intents and one's `by` a superset of the other's can share via roll-up instead of two independent passes; must consult #256's grouping-strategy legality before assuming a `SharedMultiSubpopulation` structure composes with a roll-up +- Combining computation between part from the sketch, and part from the raw data to meet an accuracy target — not yet tracked + +Cross-query, not just per-node: +- Semantic-equivalent rewriting (e.g. `avg` → `sum`/`count`) to increase how often the optimizations above apply — tracked as **#253**, landing as a `ReplacementStrategy` rather than a bespoke before/after-CSE heuristic: once #252's search exists, both the original and rewritten forms are just two competing candidates, and whichever lets more sharing happen elsewhere wins on cost +- CSE across aggregations, and group-by key management — #251 turns `share_common_subtrees`'s binary share/don't-share into a real candidate pair; #254 extends the same idea to *non-identical* (subset) group-by keys, which today's structural-equality-only CSE cannot see at all + +## Applicability reporting + +`crates/asap-aware-mapping/src/applicability.rs` (issue #247) reports "is optimization X applicable, and where" by re-walking the tree itself for each of its two rules. Tracked as **#257**: once #251/#252 exist, rebuild it as a read-only view over the search's resulting candidate-plan space instead — "which optimizations/summaries are applicable" and "what does this site's candidate list contain" become the same question, so there is exactly one place (the search) that computes it. ## Summary properties to model From 0a51bb6e0be1cc5a36657166c48675486625ce7d Mon Sep 17 00:00:00 2001 From: Milind Srivastava Date: Sun, 23 Aug 2026 12:10:51 -0400 Subject: [PATCH 2/5] changes for readability --- docs/asap_aware_mapping.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/asap_aware_mapping.md b/docs/asap_aware_mapping.md index 1440598d..f3b21ef5 100644 --- a/docs/asap_aware_mapping.md +++ b/docs/asap_aware_mapping.md @@ -6,20 +6,20 @@ The input is a pre-ASAP plan and the output is a set of candidate post-ASAP plan Based on any given accuracy targets, it can also assign parameters to those sketches (implemented today — `boundary::implementation_for`'s `bind_summary_with` sizes each candidate via `CostModel::size_params`; see `default_size_params`'s per-family formulas). This layer **does not** assign physical resources like CPU and memory to nodes in the plan. -This document tracks issue #33 ("add logic to detect which optimizations/summaries are applicable to a query workload"); the sub-issues cited below are where each piece below is actually being implemented. +This document tracks issue #33 ("add logic to detect which optimizations/summaries are applicable to a query workload"). The sub-issues cited below are where each piece below is actually being implemented. ## Key concepts - TargetSubDAG: Pre-ASAP sub-DAG that is a candidate to be replaced by a post-ASAP sub-DAG - ReplacementSubDAG: Candidate post-ASAP sub-DAG to replace a pre-ASAP sub-DAG -- ReplacementStrategy: Each strategy defines one TargetSubDAG match and every valid ReplacementSubDAG for it (not ranked, not filtered — every strategy's job is to be exhaustive, not to decide) +- ReplacementStrategy: Each strategy defines one TargetSubDAG match and every valid ReplacementSubDAG for it. ReplacementStratey only suggests strategies, it does not rank or filter them or decide which is best. - CostModel: Estimates the cost of a post-ASAP plan. Can be based on heuristics or empirical estimates -Tracked as **#251**: today, the two decisions this crate already owns — `boundary::implementation_for` (which summary family/kind realizes an `AggIntent`) and `cse::share_common_subtrees` (which subtrees can be shared) — each collapse straight to one answer instead of exposing themselves as a `ReplacementStrategy` with a candidate list. #251 generalizes both into the trait above, as the first two real `impl ReplacementStrategy`s (no new decision procedure, same discipline `applicability.rs` (#247) already used for these two). +Currently, this crate has logic for two decisions: (a) which summary family/kind realizes an `AggIntent` (`boundary::implementation_for`), and (b) which subtrees can be shared (`cse::share_common_subtrees`). These are implemented as separate code. #251 generalizes both of these to use the `ReplacementStrategy` trait. ## Replacement plan search -Tracked as **#252**, implementing the pseudocode below for real: +Tracked as **#252**. ``` input_replacement_strategies: List[ReplacementStrategy] @@ -91,7 +91,7 @@ chosen implementation Selecting a sketch: - Different sketches (KLL vs DDSketch) — today only *ranked* (`CostModel::rank_candidates` takes the head); exposed as real alternative candidates once #251 lands - Different parameters for same sketch -- Hydra vs sketch-per-subpopulation (exact treatment of subpopulations) — tracked as **#256**: a new axis orthogonal to `SketchKind`/`SamplingKind`/…, `GroupingStrategy::{PerSubpopulationInstance, SharedMultiSubpopulation}` (named for sharing across a query's own subpopulations, not multi-tenant in the deployment-isolation sense), with `HydraKind`/`HydraParams` mirroring the existing per-family `(Kind, Params)` pattern +- Hydra vs sketch-per-subpopulation (exact treatment of subpopulations) — tracked as **#256**: a new axis orthogonal to `SketchKind`/`SamplingKind`/…, `GroupingStrategy::{PerSubpopulationInstance, SharedMultiSubpopulation}` (named for sharing across a query's own subpopulations), with `HydraKind`/`HydraParams` mirroring the existing per-family `(Kind, Params)` pattern - Single-level Hydra (what the paper talks about) or multi-level Hydra (e.g. CMS on top of CMS on top of CMS) — not yet tracked; a refinement of #256's `HydraParams` once single-level lands - Sliding window vs tumbling window computation (this is specific to ASAPCollector and ASAPQuery's precompute engine) — not yet tracked here - Sliding window sketches (e.g. Promsketch) vs exact treatment of time — not yet tracked here From 32ca37f7daac660a27d36a8098a5f030b698c030 Mon Sep 17 00:00:00 2001 From: zz_y Date: Sun, 23 Aug 2026 11:38:35 -0600 Subject: [PATCH 3/5] docs(asap-aware-mapping): plain-English rewrite per Milind's PR #258/#259 comments - MEMO-sharing bullet: spell out why flat plan lists blow up and how Rc-sharing avoids it, without leaning on jargon. - Drop the docs/cse-cost-model-decision.md (#237) history/scope-change framing; keep just the forward-looking design rationale. - Applicability-reporting paragraph: explain MEMO groups concretely instead of the abstract 'candidate-plan space' framing. --- docs/asap_aware_mapping.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/asap_aware_mapping.md b/docs/asap_aware_mapping.md index f3b21ef5..ef45eafa 100644 --- a/docs/asap_aware_mapping.md +++ b/docs/asap_aware_mapping.md @@ -46,9 +46,9 @@ output: candidate_plans Two things #252 has to get right that this pseudocode leaves open: - **Dedup** must be structural-hash-based, reusing `pre_asap::cse`'s existing `InternTable`/`structural_hash` machinery (hash as a filter, `PartialEq` as the real decision) — not `Vec` containment over whole serialized plans. -- **MEMO-style sharing across candidate plans, not a flat plan list** — a naive flat list of whole candidate plans duplicates every untouched subtree across every candidate (a workload with N independently-choosable sites produces up to 2^N flat plans). Each distinct `TargetSubDAG` becomes a MEMO group holding its alternative `ReplacementSubDAG`s, so two candidate plans differing at one site still share every other node by `Rc`, the same way `share_common_subtrees` already shares identical subtrees today. +- **MEMO-style sharing across candidate plans, not a flat plan list** — don't store whole candidate plans separately; share the parts they have in common. Listing out every full candidate plan means copying the entire unchanged rest of the DAG into each one — with N spots in the plan where alternatives can be independently chosen, that's up to 2^N full plan copies, almost all of it duplicate data. Instead, each spot where a replacement could happen (`TargetSubDAG`) gets its own small group listing just its alternatives (`ReplacementSubDAG`s), MEMO-style. Two candidate plans that differ at only one spot then literally point at the same shared nodes (`Rc`) everywhere else, instead of each owning its own copy — the same sharing trick `share_common_subtrees` already uses today, just applied to every decision point instead of only CSE. -This is a genuine change of scope from `docs/cse-cost-model-decision.md` (issue #237), which deliberately chose a direct cost comparison over "full Volcano/Cascades-scale infrastructure" for *one* binary, single-candidate-pair decision (share a CSE'd subtree or don't) — reasoning at the time that "this repo has no plan-enumeration/DP-search engine anywhere" and didn't need one for that narrow question. #252 is where that stops being true, for the reason #237 itself named: once multiple interacting axes exist at once (sketch family/kind, roll-up vs. recompute, Hydra vs. per-subpopulation, semantic rewrite), a per-decision-point heuristic can't see interactions across sites the way a real candidate-plan search can. `CostModel::cse_share_decision`'s existing recompute-vs-maintenance comparison isn't thrown away — it becomes the cost function backing the CSE `ReplacementStrategy`'s two candidates (share vs. recompute-independently) inside this engine, so the final `sorted_by(cost_model)` step reuses it rather than re-solving the same comparison a second way. +A per-decision-point heuristic can't see interactions across sites the way a real candidate-plan search can: sketch family/kind, roll-up vs. recompute, Hydra vs. per-subpopulation, and semantic rewrite all interact, so deciding each one in isolation can miss a plan that's better overall. `CostModel::cse_share_decision`'s existing recompute-vs-maintenance comparison isn't thrown away — it becomes the cost function backing the CSE `ReplacementStrategy`'s two candidates (share vs. recompute-independently) inside this engine, so the final `sorted_by(cost_model)` step reuses it rather than re-solving the same comparison a second way. ## Summary mapping @@ -104,7 +104,7 @@ Cross-query, not just per-node: ## Applicability reporting -`crates/asap-aware-mapping/src/applicability.rs` (issue #247) reports "is optimization X applicable, and where" by re-walking the tree itself for each of its two rules. Tracked as **#257**: once #251/#252 exist, rebuild it as a read-only view over the search's resulting candidate-plan space instead — "which optimizations/summaries are applicable" and "what does this site's candidate list contain" become the same question, so there is exactly one place (the search) that computes it. +`crates/asap-aware-mapping/src/applicability.rs` (issue #247) reports "is optimization X applicable, and where" by re-walking the tree itself for each of its two rules. Tracked as **#257**: once #251/#252 exist, rebuild it as a read-only view over the search's MEMO groups instead of a second independent tree-walk. Once the search runs, every `TargetSubDAG` match site already has a group listing which `ReplacementStrategy`s produced a candidate there — a sketch strategy contributing a `ReplacementSubDAG` at some site *is* "sketch approximation is applicable here." So "is optimization X applicable, and where" is answered by reading a group's contents, not by a rule that re-derives the same thing a second way. ## Summary properties to model From 3ac0c4ebc940694f09f6ec02635c4855b9ba14f3 Mon Sep 17 00:00:00 2001 From: Zeying Zhu <50204836+zzylol@users.noreply.github.com> Date: Sun, 23 Aug 2026 13:54:18 -0400 Subject: [PATCH 4/5] Revise ASAP-aware mapping documentation for clarity Updated the documentation for ASAP-aware mapping to improve clarity and structure. Enhanced sections on key concepts, goals, and design principles, and corrected formatting issues. --- docs/asap_aware_mapping.md | 973 ++++++++++++++++++++++++++++++++++--- 1 file changed, 905 insertions(+), 68 deletions(-) diff --git a/docs/asap_aware_mapping.md b/docs/asap_aware_mapping.md index ef45eafa..880ced83 100644 --- a/docs/asap_aware_mapping.md +++ b/docs/asap_aware_mapping.md @@ -1,118 +1,955 @@ -# ASAP-aware mapping +# ASAP-Aware Mapping -ASAP-aware mapping decides **whether and how an intent can be answered by a summary** rather than by scanning raw data. +## Overview -The input is a pre-ASAP plan and the output is a set of candidate post-ASAP plans. This layer decides what kind of sketches can be used to satisfy a query. -Based on any given accuracy targets, it can also assign parameters to those sketches (implemented today — `boundary::implementation_for`'s `bind_summary_with` sizes each candidate via `CostModel::size_params`; see `default_size_params`'s per-family formulas). -This layer **does not** assign physical resources like CPU and memory to nodes in the plan. +ASAP-aware mapping decides **whether and how a query intent can be answered using summaries instead of scanning raw data**. -This document tracks issue #33 ("add logic to detect which optimizations/summaries are applicable to a query workload"). The sub-issues cited below are where each piece below is actually being implemented. +Given a logical query plan, the mapping layer explores alternative plans that may use sketches, exact summaries, shared computation, roll-ups, semantic rewrites, or combinations of these techniques. -## Key concepts +The input is a **pre-ASAP plan** describing what the query wants to compute. The output is a set of **candidate post-ASAP plans** describing different valid ways to realize that computation. -- TargetSubDAG: Pre-ASAP sub-DAG that is a candidate to be replaced by a post-ASAP sub-DAG -- ReplacementSubDAG: Candidate post-ASAP sub-DAG to replace a pre-ASAP sub-DAG -- ReplacementStrategy: Each strategy defines one TargetSubDAG match and every valid ReplacementSubDAG for it. ReplacementStratey only suggests strategies, it does not rank or filter them or decide which is best. -- CostModel: Estimates the cost of a post-ASAP plan. Can be based on heuristics or empirical estimates +For example, a percentile query might be answered by: -Currently, this crate has logic for two decisions: (a) which summary family/kind realizes an `AggIntent` (`boundary::implementation_for`), and (b) which subtrees can be shared (`cse::share_common_subtrees`). These are implemented as separate code. #251 generalizes both of these to use the `ReplacementStrategy` trait. +```text +Quantile(latency, 0.99) + + ↓ + +KLL +DDSketch +exact aggregation +``` + +Which alternative is preferable depends on requirements such as accuracy, latency, storage, update cost, and the surrounding query workload. + +ASAP-aware mapping therefore answers two questions: + +1. **What transformations are valid?** +2. **What combinations of those transformations form useful candidate plans?** + +It does **not** assign physical resources such as CPU or memory to operators. Physical resource allocation belongs to a later planning stage. + +--- + +## Goals + +The mapping layer should support three capabilities. + +### 1. Discover valid alternatives + +For each relevant part of a query plan, determine which exact or approximate implementations can preserve the query's required semantics. + +For example: + +```text +DistinctCount(user_id) + → exact distinct counting + → HyperLogLog + +Quantile(latency, 0.99) + → exact quantile + → KLL + → DDSketch +``` + +A query intent may therefore have more than one valid realization. + +### 2. Explore interactions between alternatives + +Optimization choices cannot always be made independently. -## Replacement plan search +For example, the best summary for one aggregation may depend on: -Tracked as **#252**. +- whether the result can be shared with another query, +- whether multiple group-by levels can be computed through roll-up, +- whether subpopulations share one summary or use separate summaries, +- whether a semantic rewrite exposes additional sharing, +- whether time windows can reuse common state, +- and whether another transformation changes the cost of maintaining the summary. +ASAP-aware mapping should therefore reason about **candidate plans as a whole**, rather than greedily choosing the best alternative at each node. + +### 3. Explain applicability + +The same information used to construct candidate plans should also answer questions such as: + +- Can this aggregation use a sketch? +- Which summary families are valid? +- Can these two computations share work? +- Can one group-by result be rolled up into another? +- Can a semantic rewrite expose additional reuse? +- Where in the query plan are these opportunities available? + +Applicability reporting should describe opportunities already discovered by the planner rather than duplicate the planner's reasoning in a separate rule system. + +--- + +# Core Abstractions + +## Target Sub-DAG + +A **Target Sub-DAG** is a region of the pre-ASAP plan that may be transformed. + +Examples include: + +- an aggregation that could be replaced by a sketch, +- two computations that could share common work, +- several group-by computations that could be related through roll-up, +- or an expression that has a semantically equivalent alternative representation. + +The target may consist of a single operator or several connected operators. + +--- + +## Replacement Sub-DAG + +A **Replacement Sub-DAG** is one valid realization of a Target Sub-DAG. + +For example: + +```text +Target: + +Quantile(latency, 0.99) + +Possible replacements: + +KLL(latency) +DDSketch(latency) +ExactQuantile(latency) ``` -input_replacement_strategies: List[ReplacementStrategy] -input_plan: pre-ASAP plan (DAG) -candidate_plans = [input_plan] -new_plans = [] -do - for candidate_plan in candidate_plans: - for strategy in input_replacement_strategies: - if candidate_plan has input_strategy.TargetSubDAG: - candidate_plan_replacements = replace(candidate_plan, strategy) - new_plans = candidate_plane_replacement - candidate_plans - new_plans = deduplicate(new_plans) - candidate_plans = candidate_plans UNION new_plans -while new_plans != [] +Another example involves computation sharing: + +```text +Target: + +Aggregate(source, by=[service, region]) +Aggregate(source, by=[service]) + +Possible replacements: + +1. Compute both independently + +2. Compute: + Aggregate(source, by=[service, region]) + then roll up to: + Aggregate(..., by=[service]) +``` + +A replacement represents a semantic alternative, not necessarily an approximation. + +--- + +## Replacement Strategy + +A **Replacement Strategy** describes a class of transformations. + +Conceptually, a strategy answers: + +> When a particular structure appears in a plan, what valid alternatives can replace it? + +Examples include: + +- replacing an aggregation with compatible summaries, +- sharing equivalent computation, +- rolling up between related group-by levels, +- rewriting an expression into an equivalent form, +- choosing different ways to organize subpopulations, +- choosing different time representations. + +A strategy proposes valid alternatives. It does not decide which alternative is globally best. + +--- + +## Cost Model + +The **Cost Model** estimates the trade-offs of candidate plans. + +Depending on the planning stage, costs may include: + +- summary storage, +- ingestion or update work, +- query latency, +- raw-data processing, +- maintenance overhead, +- expected accuracy, +- and workload-dependent reuse. + +The cost model is intentionally separate from transformation legality. + +A replacement strategy answers: + +> Is this plan valid? + +The cost model answers: + +> How attractive is this valid plan relative to the alternatives? + +This separation allows the same planning framework to support different cost models, including heuristic, analytical, and empirically learned models. + +--- + +# Candidate-Plan Search + +The central design principle is that ASAP-aware mapping should **preserve alternatives long enough to reason about their interactions**. + +Suppose a plan contains several independent-looking decision points: + +```text + Query workload + | + +------------+------------+ + | | + Quantile Group-by + | | + KLL / DDSketch independent / roll-up +``` + +Choosing KLL immediately because it appears locally cheapest may be wrong if another summary enables more efficient sharing elsewhere in the plan. + +Similarly, deciding independently whether to share two computations may miss a better plan produced after semantic rewriting. + +The planner should therefore construct a search space containing valid alternatives and evaluate combinations of those alternatives. + +--- + +## Shared Representation of Alternatives + +Candidate plans often differ in only a small part of the overall query DAG. + +For example: + +```text + shared source + | + shared filters + | + +------+------+ + | | + KLL DDSketch + | | + +------+------+ + | + shared remainder +``` + +The planner should represent common structure once and attach alternatives only at the decision points where plans differ. + +Conceptually, each decision point forms an **alternative group**: + +```text +Group A: Quantile implementation + - KLL + - DDSketch + - exact quantile + +Group B: Subpopulation organization + - one summary per subpopulation + - shared multi-subpopulation summary + +Group C: Related aggregations + - compute independently + - compute once and roll up +``` + +A candidate plan corresponds to a compatible selection across these groups. + +This avoids representing every full plan independently when most of their structure is identical. -sort candidate_plans based on CostModel +--- -output: candidate_plans +## Global Rather Than Local Decisions +The planner should evaluate alternatives at the plan level because several dimensions interact: + +```text +summary family + × +summary parameters + × +subpopulation organization + × +roll-up structure + × +computation sharing + × +semantic rewrites + × +time representation ``` -Two things #252 has to get right that this pseudocode leaves open: +A locally optimal choice may prevent a globally better combination. + +The planner should therefore retain alternatives until enough context exists to compare them as complete candidate plans. + +The design may prune clearly dominated alternatives, but pruning should preserve choices that could become useful because of interactions elsewhere in the plan. -- **Dedup** must be structural-hash-based, reusing `pre_asap::cse`'s existing `InternTable`/`structural_hash` machinery (hash as a filter, `PartialEq` as the real decision) — not `Vec` containment over whole serialized plans. -- **MEMO-style sharing across candidate plans, not a flat plan list** — don't store whole candidate plans separately; share the parts they have in common. Listing out every full candidate plan means copying the entire unchanged rest of the DAG into each one — with N spots in the plan where alternatives can be independently chosen, that's up to 2^N full plan copies, almost all of it duplicate data. Instead, each spot where a replacement could happen (`TargetSubDAG`) gets its own small group listing just its alternatives (`ReplacementSubDAG`s), MEMO-style. Two candidate plans that differ at only one spot then literally point at the same shared nodes (`Rc`) everywhere else, instead of each owning its own copy — the same sharing trick `share_common_subtrees` already uses today, just applied to every decision point instead of only CSE. +--- -A per-decision-point heuristic can't see interactions across sites the way a real candidate-plan search can: sketch family/kind, roll-up vs. recompute, Hydra vs. per-subpopulation, and semantic rewrite all interact, so deciding each one in isolation can miss a plan that's better overall. `CostModel::cse_share_decision`'s existing recompute-vs-maintenance comparison isn't thrown away — it becomes the cost function backing the CSE `ReplacementStrategy`'s two candidates (share vs. recompute-independently) inside this engine, so the final `sorted_by(cost_model)` step reuses it rather than re-solving the same comparison a second way. +# Mapping Query Intents to Summaries -## Summary mapping +A core responsibility of ASAP-aware mapping is translating logical aggregation intents into compatible summary families. Representative mappings include: ```text Count - -> exact counter / count summary + → exact counter DistinctCount(field) - -> HyperLogLog-family summary + → exact distinct accumulator + → HyperLogLog-family summary Quantile(field, q) - -> quantile sketch family such as KLL / DDSketch + → exact quantile accumulator + → KLL-family summary + → DDSketch-family summary TopK(key, Count, k) - -> heavy-hitter family such as SpaceSaving + → exact frequency aggregation + → heavy-hitter summary such as SpaceSaving ``` -The mapping is not necessarily one-to-one. Multiple summary candidates may satisfy one -intent, and a cost model may rank those candidates. +These mappings are intentionally **one-to-many**. For example: ```text Quantile(latency, 0.99) + ↓ -Candidate summaries: + +Candidate realizations + KLL DDSketch - exact accumulator + exact quantile + + ↓ + +Accuracy, storage, update cost, +query latency, and workload context + + ↓ + +Candidate-plan ranking +``` + +An exact implementation should remain a valid candidate when appropriate. ASAP-aware mapping is not simply a "replace operators with sketches" pass; it explores both exact and approximate realizations. + +--- + +# Accuracy-Aware Parameterization + +Choosing a summary family is only part of the decision. + +A summary may itself have several valid configurations: + +```text +Quantile(latency, 0.99) + + ↓ + +KLL + ├── smaller state + ├── medium state + └── larger state + +DDSketch + ├── tighter relative error + └── looser relative error +``` + +The configuration determines trade-offs among: + +- accuracy, +- storage, +- update cost, +- merge cost, +- and query latency. + +Given an accuracy target, the mapping layer should expose configurations that satisfy the target and allow the cost model to compare them with other valid plans. + +Accuracy requirements therefore act as **constraints on the search space**, rather than as a separate decision made after a summary family has already been chosen. + +--- + +# Design Dimensions + +ASAP-aware mapping should support several largely orthogonal dimensions of optimization. + +## Summary Family + +Different summary algorithms may implement the same logical intent. + +For example: + +```text +Quantile + → KLL + → DDSketch + → exact quantile +``` + +The planner should preserve these as alternatives rather than committing to one family before considering the rest of the plan. + +--- + +## Summary Parameters + +The same summary algorithm may admit multiple parameterizations. + +Increasing summary size may improve accuracy while increasing memory and update cost. + +Different parameterizations should therefore be represented as distinct alternatives when they lead to meaningful accuracy or cost trade-offs. + +--- + +## Subpopulation Organization + +Queries often compute the same statistic over many subpopulations: + +```text +latency by service +latency by region +latency by customer +``` + +There are at least two broad ways to organize summaries. + +### Per-subpopulation summaries + +Maintain a separate summary for each subpopulation. + +```text +service A → sketch +service B → sketch +service C → sketch +``` + +This is conceptually simple and provides strong isolation between groups. + +### Shared multi-subpopulation summaries + +Use a structure that represents many subpopulations together. + +```text + shared summary + / | \ + service A service B service C +``` + +Hydra-style structures are one example of this approach. + +These alternatives affect memory, update cost, query cost, accuracy, and compatibility with other transformations. + +Subpopulation organization should therefore be modeled as a separate design dimension rather than being implicitly tied to a particular summary family. + +--- + +## Hierarchical Summary Structures + +Shared summaries may themselves have multiple levels. + +For example: + +```text + coarse summary + / \ + intermediate intermediate + / \ + leaf summary leaf summary +``` + +A single-level structure may be sufficient for some workloads, while hierarchical structures may scale better for others. + +The hierarchy should be treated as a property of the plan rather than assumed to be fixed by the summary family. + +--- + +## Time Organization + +Windowed analytics introduces another independent design choice. + +A query such as: + +```text +p99 latency over the last 30 minutes +``` + +might be maintained using: + +- tumbling windows, +- sliding-window computation, +- mergeable summaries over smaller time buckets, +- sliding-window-specific summaries, +- or exact treatment of time. + +Time organization affects both accuracy and the ability to reuse summaries across queries with different windows. + +It should therefore be modeled explicitly for windowed workloads. + +--- + +## Group-By Roll-Up + +Related aggregation levels may reuse computation. + +Consider: + +```text +latency BY service, region + +latency BY service +``` + +If the underlying summary is mergeable, the finer-grained aggregation may be used to derive the coarser one: + +```text +Raw data + | +Aggregate BY service, region + | +Roll up regions + | +Aggregate BY service +``` + +instead of: + +```text +Raw data ──→ Aggregate BY service, region + +Raw data ──→ Aggregate BY service +``` + +Whether this transformation is valid depends on the properties of the underlying summary and how subpopulations are represented. + +The planner therefore cannot treat roll-up as an isolated optimization. It must consider its compatibility with the selected summary and grouping organization. + +--- + +## Hybrid Raw-Data and Summary Execution + +Some accuracy requirements may be satisfied most efficiently using both summarized and raw data. + +Conceptually: + +```text + Query + | + +-------+-------+ + | | + Summary Raw data + | | + +-------+-------+ + | + final result +``` + +Examples may include refining a summary-based estimate using a limited raw-data scan, or keeping exact information for only part of the domain. + +Hybrid execution introduces another point in the design space between fully summarized and fully exact computation. + +--- + +# Cross-Query Optimization + +Many important opportunities are visible only when considering multiple queries or multiple branches of a workload together. + +## Common Computation + +Equivalent computations should be shareable when doing so reduces total work. + +For example: + +```text +Query A: Filter(source, service="api") → Aggregate(...) +Query B: Filter(source, service="api") → Aggregate(...) +``` + +The shared portion can potentially be computed once and reused. + +However, sharing is not always free. A shared result may require additional maintenance, storage, or coordination. + +Both alternatives should therefore remain visible to the planner: + +```text +compute independently +vs. +compute once and share +``` + +The cost model can then compare them in the context of the whole workload. + +--- + +## Semantic-Equivalent Rewriting + +Two queries that are logically related may not initially expose reusable structure. + +For example: + +```text +avg(x) +``` + +can be represented as: + +```text +sum(x) / count(x) +``` + +A semantic rewrite may make it possible to share `sum` or `count` with other queries. + +The planner should therefore treat the original and rewritten forms as alternative plans rather than assuming semantic rewrites are always beneficial. + +For example: + +```text +Original: + avg(x) + +Alternative: + sum(x) + count(x) + ↓ + final division +``` + +The rewritten form may incur more local work while enabling substantially more cross-query sharing elsewhere. + +Only plan-level comparison can capture this trade-off correctly. + +--- + +## Sharing Across Group-By Levels + +Structural equality is not the only source of reuse. + +Consider: + +```text +Query A: Aggregate BY service, region +Query B: Aggregate BY service +``` + +The two operators are not identical, but their grouping keys are related. + +If the aggregation is mergeable, Query B may be derived by rolling up Query A. + +This creates reuse opportunities across **hierarchically related groupings**, not just identical subtrees. + +The legality and cost of this transformation depend on: + +- summary mergeability, +- grouping organization, +- summary accuracy behavior, +- and the relative maintenance and query costs of the two alternatives. + +--- + +# Applicability Reporting + +ASAP-aware mapping should make its discovered opportunities visible to users and other components. + +For each relevant region of the plan, the planner should be able to report: + +- which transformations are applicable, +- what alternatives each transformation introduces, +- what conditions make those alternatives legal, +- and which parts of the plan they affect. + +For example: + +```text +Aggregation: Quantile(latency, 0.99) + +Applicable alternatives: + - exact quantile + - KLL + - DDSketch + +Additional opportunities: + - share source filtering with Query B + - reuse finer-grained aggregation through roll-up +``` + +Applicability is therefore a **view of the candidate search space**, not a second optimization engine. + +This keeps explanations consistent with the plans the optimizer can actually produce. + +--- + +# Summary Properties + +To determine whether transformations are valid, ASAP-aware mapping needs a common description of summary capabilities. + +Important properties include the following. + +## Mergeability + +Can two independently maintained summaries be combined to produce a summary of their union? + +Mergeability enables: + +- distributed aggregation, +- time-bucket merging, +- group-by roll-up, +- hierarchical summaries, +- and some forms of shared computation. + +--- + +## Subpopulation Awareness + +Can one summary represent multiple subpopulations and answer queries for individual subsets? + +This determines whether shared multi-subpopulation designs are possible. + +--- + +## Subtractability + +Can one summary be removed from another? + +Conceptually: + +```text +Summary(A ∪ B) - Summary(B) → Summary(A) +``` + +Subtractability is useful for sliding windows, dynamic partitions, and incremental maintenance. + +--- + +## Deletion Support + +Can individual items be removed from a summary? + +Deletion support may be necessary for: + +- sliding windows, +- corrections, +- mutable datasets, +- and retractions. + +This is distinct from subtracting one complete summary from another. + +--- + +## Time Awareness + +Does the summary natively model time or window semantics? + +A time-aware summary may support operations that are difficult or expensive using a time-agnostic sketch. + +--- + +## Linearity + +Can the summary participate in linear combinations or related algebraic operations? + +Linearity may enable composition, subtraction, hierarchical aggregation, or recovery of related statistics. + +--- + +## Accuracy Under Continued Insertion + +Does the summary's error behavior change as more items are inserted? + +Some summaries provide guarantees largely independent of stream length, while others may degrade or require resizing. + +The planner needs this information when selecting long-lived summaries. + +--- + +## Composability + +Can a summary serve as the input to another logical or summary operator? + +For example: + +```text +raw data + ↓ +summary A + ↓ +summary B +``` + +or: + +```text +fine-grained summaries ↓ -Cost / accuracy / latency constraints + roll-up ↓ -chosen implementation +coarser summary ``` -## Degrees of freedom we should explore +Composability determines which multi-stage candidate plans are legal. -Selecting a sketch: -- Different sketches (KLL vs DDSketch) — today only *ranked* (`CostModel::rank_candidates` takes the head); exposed as real alternative candidates once #251 lands -- Different parameters for same sketch -- Hydra vs sketch-per-subpopulation (exact treatment of subpopulations) — tracked as **#256**: a new axis orthogonal to `SketchKind`/`SamplingKind`/…, `GroupingStrategy::{PerSubpopulationInstance, SharedMultiSubpopulation}` (named for sharing across a query's own subpopulations), with `HydraKind`/`HydraParams` mirroring the existing per-family `(Kind, Params)` pattern -- Single-level Hydra (what the paper talks about) or multi-level Hydra (e.g. CMS on top of CMS on top of CMS) — not yet tracked; a refinement of #256's `HydraParams` once single-level lands -- Sliding window vs tumbling window computation (this is specific to ASAPCollector and ASAPQuery's precompute engine) — not yet tracked here -- Sliding window sketches (e.g. Promsketch) vs exact treatment of time — not yet tracked here -- AHA vs treating hierarchical subpopulations independently — tracked as **#254**: two `Aggregate` nodes over the same shared source with mergeable intents and one's `by` a superset of the other's can share via roll-up instead of two independent passes; must consult #256's grouping-strategy legality before assuming a `SharedMultiSubpopulation` structure composes with a roll-up -- Combining computation between part from the sketch, and part from the raw data to meet an accuracy target — not yet tracked +--- -Cross-query, not just per-node: -- Semantic-equivalent rewriting (e.g. `avg` → `sum`/`count`) to increase how often the optimizations above apply — tracked as **#253**, landing as a `ReplacementStrategy` rather than a bespoke before/after-CSE heuristic: once #252's search exists, both the original and rewritten forms are just two competing candidates, and whichever lets more sharing happen elsewhere wins on cost -- CSE across aggregations, and group-by key management — #251 turns `share_common_subtrees`'s binary share/don't-share into a real candidate pair; #254 extends the same idea to *non-identical* (subset) group-by keys, which today's structural-equality-only CSE cannot see at all +# Validity and Compatibility -## Applicability reporting +Individual transformations may be valid in isolation but invalid in combination. -`crates/asap-aware-mapping/src/applicability.rs` (issue #247) reports "is optimization X applicable, and where" by re-walking the tree itself for each of its two rules. Tracked as **#257**: once #251/#252 exist, rebuild it as a read-only view over the search's MEMO groups instead of a second independent tree-walk. Once the search runs, every `TargetSubDAG` match site already has a group listing which `ReplacementStrategy`s produced a candidate there — a sketch strategy contributing a `ReplacementSubDAG` at some site *is* "sketch approximation is applicable here." So "is optimization X applicable, and where" is answered by reading a group's contents, not by a rule that re-derives the same thing a second way. +For example: + +```text +summary family + ✓ supports merge + +grouping strategy + ✓ supports multiple subpopulations + +roll-up + ? +``` + +The planner must verify that the complete combination preserves the intended semantics. + +Compatibility checks may involve: + +- whether a summary can be merged, +- whether its accuracy guarantees survive composition, +- whether the chosen grouping strategy supports roll-up, +- whether subtraction or deletion is required, +- whether a semantic rewrite preserves approximation guarantees, +- and whether time organization is compatible with the selected summary. + +This motivates modeling summary capabilities explicitly instead of encoding assumptions inside individual optimization rules. + +--- + +# Planning Flow + +At a high level, ASAP-aware mapping follows this flow: + +```text +Pre-ASAP query plan + | + v +Discover transformable regions + | + v +Generate valid alternatives + | + v +Check compatibility between alternatives + | + v +Build shared candidate-plan search space + | + v +Apply accuracy and semantic constraints + | + v +Estimate candidate-plan costs + | + v +Rank or select candidate post-ASAP plans +``` + +Each stage has a distinct responsibility. + +### Discovery + +Find places where an alternative realization may exist. + +### Alternative generation + +Enumerate semantically valid replacements. + +### Compatibility + +Determine which alternatives can coexist. + +### Constraint checking + +Remove candidates that cannot satisfy accuracy or semantic requirements. + +### Costing + +Estimate the trade-offs of remaining candidates. + +### Ranking + +Expose the most attractive post-ASAP plans to the next planning stage. + +--- + +# Non-Goals + +ASAP-aware mapping is not responsible for: + +- assigning CPU cores, +- assigning memory budgets to execution nodes, +- choosing machine placement, +- scheduling execution, +- managing runtime admission control, +- or performing low-level execution tuning. + +Those decisions belong to later physical planning or runtime layers. + +ASAP-aware mapping focuses on the logical question: + +> **What summarized or shared computation could answer this workload, and which combinations are worth considering?** + +--- + +# Design Principles + +The design should follow several principles. + +### Preserve alternatives + +Do not commit to one sketch, rewrite, or sharing decision before interactions with the rest of the plan are visible. + +### Separate legality from cost + +Transformation logic determines what is valid. The cost model determines what is desirable. + +### Treat exact computation as a candidate + +Approximation is an option, not an assumption. + +### Model optimization dimensions independently + +Summary family, summary parameters, grouping strategy, time organization, sharing, and semantic rewrites should be composable dimensions whenever possible. + +### Share the search space + +Candidate plans should reuse common structure rather than duplicating entire DAGs for every combination of choices. + +### Make applicability explainable + +The planner should be able to explain which optimizations are possible and where they apply based on the same candidate space used for optimization. + +### Make summary capabilities explicit + +Properties such as mergeability, subtractability, deletion support, time awareness, and composability should drive transformation legality. + +--- + +# Summary + +ASAP-aware mapping is the logical optimization layer that bridges query intent and summary-based execution. + +It transforms: + +```text +"What does the workload want to compute?" +``` + +into: + +```text +"What exact, approximate, shared, or rewritten plans could compute it?" +``` -## Summary properties to model +The key challenge is not simply matching an aggregation to a sketch. It is exploring a multidimensional design space in which summary choice, accuracy, grouping structure, reuse, semantic rewriting, time organization, and cross-query optimization interact. -- Mergeable? -- Subpopulation aware? -- Subtractable? -- Able to delete an item? -- Time aware? -- Linearability? -- Does accuracy drop when more items are inserted? -- Can a summary work as an inner operator for other operators? +The output is therefore best viewed not as one immediate rewrite, but as a **shared search space of valid candidate post-ASAP plans** that can be compared using a cost model and passed to later planning stages. From 417d8ec2c69f84fa46822884df0213773660cfe6 Mon Sep 17 00:00:00 2001 From: Zeying Zhu <50204836+zzylol@users.noreply.github.com> Date: Sun, 23 Aug 2026 14:07:15 -0400 Subject: [PATCH 5/5] Enhance glossary and definitions in ASAP-aware mapping Added glossary terms and clarified definitions related to ASAP-aware mapping, including distinctions between alternatives and candidate plans. --- docs/asap_aware_mapping.md | 88 +++++++++++++++++++++++++++----------- 1 file changed, 64 insertions(+), 24 deletions(-) diff --git a/docs/asap_aware_mapping.md b/docs/asap_aware_mapping.md index 880ced83..7c63e941 100644 --- a/docs/asap_aware_mapping.md +++ b/docs/asap_aware_mapping.md @@ -1,5 +1,19 @@ # ASAP-Aware Mapping +## Glossary + +- **Pre-ASAP plan**: The logical query plan before ASAP-aware optimizations are considered. +- **Post-ASAP plan**: A logical plan that includes one or more ASAP-aware choices, such as summaries, sharing, roll-ups, or semantic rewrites. +- **Target Sub-DAG**: A region of the pre-ASAP plan where a transformation may apply. +- **Alternative**: One valid local realization of a Target Sub-DAG. For example, a quantile aggregation may have KLL, DDSketch, and exact aggregation as alternatives. +- **Transformation**: A rule that recognizes a Target Sub-DAG and produces one or more valid alternatives. +- **Candidate Plan**: A complete post-ASAP plan formed by choosing compatible alternatives across the plan. +- **Cost Model**: A model used to compare valid candidate plans according to criteria such as storage, update cost, query latency, and accuracy. + +The distinction between **Alternative** and **Candidate Plan** is important: an alternative is a local choice at one decision point, while a candidate plan is a complete plan that combines choices across all relevant decision points. + +--- + ## Overview ASAP-aware mapping decides **whether and how a query intent can be answered using summaries instead of scanning raw data**. @@ -25,7 +39,7 @@ Which alternative is preferable depends on requirements such as accuracy, latenc ASAP-aware mapping therefore answers two questions: 1. **What transformations are valid?** -2. **What combinations of those transformations form useful candidate plans?** +2. **What combinations of alternatives form useful candidate plans?** It does **not** assign physical resources such as CPU or memory to operators. Physical resource allocation belongs to a later planning stage. @@ -37,7 +51,7 @@ The mapping layer should support three capabilities. ### 1. Discover valid alternatives -For each relevant part of a query plan, determine which exact or approximate implementations can preserve the query's required semantics. +For each relevant part of a query plan, determine which exact or approximate realizations preserve the query's required semantics. For example: @@ -52,7 +66,7 @@ Quantile(latency, 0.99) → DDSketch ``` -A query intent may therefore have more than one valid realization. +A query intent may therefore have more than one valid alternative. ### 2. Explore interactions between alternatives @@ -88,22 +102,22 @@ Applicability reporting should describe opportunities already discovered by the ## Target Sub-DAG -A **Target Sub-DAG** is a region of the pre-ASAP plan that may be transformed. +A **Target Sub-DAG** is a region of the pre-ASAP plan where a transformation may apply. Examples include: -- an aggregation that could be replaced by a sketch, +- an aggregation that could be answered by a sketch, - two computations that could share common work, - several group-by computations that could be related through roll-up, -- or an expression that has a semantically equivalent alternative representation. +- or an expression that has a semantically equivalent representation. The target may consist of a single operator or several connected operators. --- -## Replacement Sub-DAG +## Alternative -A **Replacement Sub-DAG** is one valid realization of a Target Sub-DAG. +An **Alternative** is one valid local realization of a Target Sub-DAG. For example: @@ -112,7 +126,7 @@ Target: Quantile(latency, 0.99) -Possible replacements: +Alternatives: KLL(latency) DDSketch(latency) @@ -127,7 +141,7 @@ Target: Aggregate(source, by=[service, region]) Aggregate(source, by=[service]) -Possible replacements: +Alternatives: 1. Compute both independently @@ -137,15 +151,15 @@ Possible replacements: Aggregate(..., by=[service]) ``` -A replacement represents a semantic alternative, not necessarily an approximation. +An alternative represents a semantic choice, not necessarily an approximation. --- -## Replacement Strategy +## Transformation -A **Replacement Strategy** describes a class of transformations. +A **Transformation** describes a class of plan changes. -Conceptually, a strategy answers: +Conceptually, a transformation answers: > When a particular structure appears in a plan, what valid alternatives can replace it? @@ -158,7 +172,33 @@ Examples include: - choosing different ways to organize subpopulations, - choosing different time representations. -A strategy proposes valid alternatives. It does not decide which alternative is globally best. +A transformation proposes valid alternatives. It does not decide which candidate plan is globally best. + +--- + +## Candidate Plan + +A **Candidate Plan** is a complete post-ASAP plan formed by choosing a compatible set of alternatives across the plan. + +For example, one candidate plan may choose: + +```text +Quantile implementation: + KLL + +Subpopulation organization: + shared multi-subpopulation summary + +Related group-bys: + roll up from finer-grained aggregation + +Semantic form: + rewrite avg as sum/count +``` + +Another candidate plan may make different choices at any of these decision points. + +The planner compares candidate plans, not isolated alternatives, when interactions between decisions matter. --- @@ -178,19 +218,19 @@ Depending on the planning stage, costs may include: The cost model is intentionally separate from transformation legality. -A replacement strategy answers: +A transformation answers: -> Is this plan valid? +> Is this alternative valid? The cost model answers: -> How attractive is this valid plan relative to the alternatives? +> How attractive is the resulting candidate plan relative to other valid candidate plans? This separation allows the same planning framework to support different cost models, including heuristic, analytical, and empirically learned models. --- -# Candidate-Plan Search +# Candidate Plan Search The central design principle is that ASAP-aware mapping should **preserve alternatives long enough to reason about their interactions**. @@ -210,7 +250,7 @@ Choosing KLL immediately because it appears locally cheapest may be wrong if ano Similarly, deciding independently whether to share two computations may miss a better plan produced after semantic rewriting. -The planner should therefore construct a search space containing valid alternatives and evaluate combinations of those alternatives. +The planner should therefore construct a search space of local alternatives and evaluate the complete candidate plans formed from their compatible combinations. --- @@ -236,7 +276,7 @@ For example: The planner should represent common structure once and attach alternatives only at the decision points where plans differ. -Conceptually, each decision point forms an **alternative group**: +Conceptually, each decision point forms an **alternative group** containing its local choices: ```text Group A: Quantile implementation @@ -253,7 +293,7 @@ Group C: Related aggregations - compute once and roll up ``` -A candidate plan corresponds to a compatible selection across these groups. +A candidate plan is formed by selecting one compatible alternative from each relevant group. This avoids representing every full plan independently when most of their structure is identical. @@ -281,7 +321,7 @@ time representation A locally optimal choice may prevent a globally better combination. -The planner should therefore retain alternatives until enough context exists to compare them as complete candidate plans. +The planner should therefore retain local alternatives until enough context exists to compare the complete candidate plans they produce. The design may prune clearly dominated alternatives, but pruning should preserve choices that could become useful because of interactions elsewhere in the plan. @@ -847,7 +887,7 @@ Build shared candidate-plan search space Apply accuracy and semantic constraints | v -Estimate candidate-plan costs +Estimate candidate plan costs | v Rank or select candidate post-ASAP plans