From 618e54ec57953b9e6b331e9a142b90dbb9b82e1d Mon Sep 17 00:00:00 2001 From: zzylol <50204836+zzylol@users.noreply.github.com> Date: Sat, 3 Oct 2026 14:08:28 +0000 Subject: [PATCH 1/2] docs: clarify common sub-DAG sharing terminology --- docs/design_docs/decisions/cse-cost-model.md | 8 +++++++- docs/design_docs/proposals/operator-sharing.md | 7 +++++++ docs/design_docs/proposals/planner-layering.md | 5 ++++- docs/develop_docs/asap-aware-mapping-architecture.md | 9 ++++++--- 4 files changed, 24 insertions(+), 5 deletions(-) diff --git a/docs/design_docs/decisions/cse-cost-model.md b/docs/design_docs/decisions/cse-cost-model.md index ed7e54e08..7ada47bc5 100644 --- a/docs/design_docs/decisions/cse-cost-model.md +++ b/docs/design_docs/decisions/cse-cost-model.md @@ -1,9 +1,15 @@ -# CSE sharing: rule-based vs. cost-based framework (issue #237) +# Common sub-DAG sharing: rule-based vs. cost-based framework (issue #237) > Status: accepted decision for the implementation described here. ## Context +Sub-DAG sharing means multiple consumers reference one operator and its +upstream dependencies. Common sub-DAG sharing uses CSE (common subexpression +elimination) to identify eligible, structurally identical computations. A +shared logical node records an opportunity for reuse; selecting maintained +state or independent execution is a separate planning decision. + [`asap_types::pre_asap::cse::share_common_sub_dags`](../../../crates/types/src/pre_asap/cse.rs) (issue #223 stages 1-2, PR #235) already *detects* every structurally-identical, legally-shareable (`Schema::unique_keys`-gated) sub-DAG and shares it diff --git a/docs/design_docs/proposals/operator-sharing.md b/docs/design_docs/proposals/operator-sharing.md index 1851d1809..f6c565c2e 100644 --- a/docs/design_docs/proposals/operator-sharing.md +++ b/docs/design_docs/proposals/operator-sharing.md @@ -324,6 +324,13 @@ A `Project`, for example, has one representation whether its input is an ordinar aggregate or a summary estimate. This proposal removes the representation boundary; it does not introduce rules for sharing computations across queries. +**Sub-DAG sharing** means multiple consumers reference the same operator node +and its upstream dependencies. **Common sub-DAG sharing** is the CSE step that +finds eligible, structurally identical sub-DAGs and replaces separate copies +with one shared instance. Physical planning determines how that common +computation is executed or materialized; consumers requiring different +execution phases may need separate instances. + ## 2. Node properties and why they differ Both operation categories use the `OperatorNode` declared in the §1.1 overview. diff --git a/docs/design_docs/proposals/planner-layering.md b/docs/design_docs/proposals/planner-layering.md index fc268c6ab..5273bfb3f 100644 --- a/docs/design_docs/proposals/planner-layering.md +++ b/docs/design_docs/proposals/planner-layering.md @@ -261,7 +261,10 @@ exploits. #### Pass 2: ASAP-aware common-subexpression elimination -ASAP-aware CSE extends traditional CSE with summary-specific sharing rules. +**Sub-DAG sharing** means several consumers reference one operator and its +upstream dependencies. Traditional CSE provides common sub-DAG sharing for +eligible, structurally identical computations. ASAP-aware CSE extends it with +summary-specific sharing rules. Computations can share work when they use identical expressions, when one summary build node supports several estimates, or when one window summary can answer their overlapping windows. diff --git a/docs/develop_docs/asap-aware-mapping-architecture.md b/docs/develop_docs/asap-aware-mapping-architecture.md index 5170f7d91..13c7b2886 100644 --- a/docs/develop_docs/asap-aware-mapping-architecture.md +++ b/docs/develop_docs/asap-aware-mapping-architecture.md @@ -60,9 +60,12 @@ Terminology used in the diagram: realizes an operation as a concrete ASAP realization; **post-ASAP** means the resulting realization form. - A **DAG** (directed acyclic graph) represents query operators whose sub-DAGs - may be shared. **CSE** (common subexpression elimination) finds equivalent - sub-DAGs and represents legal reuse by making them the same shared node. - Rust's `Rc` (reference-counted pointer) records that shared node identity. + may be shared. **Sub-DAG sharing** means multiple consumers reference one + operator and its upstream dependencies. **Common sub-DAG sharing** is the + CSE (common subexpression elimination) step that finds eligible, structurally + identical sub-DAGs and makes them one shared instance. Rust's `Rc` + (reference-counted pointer) records that identity. Physical planning chooses + how to execute or materialize the common computation. - A **target** is one replaceable site. A **candidate** is one valid alternative for it. `Replacement::Summary` is a constructed post-ASAP summary—maintained state such as an exact accumulator or an approximate sketch—while From adaf951a12f420c69e0b17eed93e7f5fa8618fd5 Mon Sep 17 00:00:00 2001 From: zzylol <50204836+zzylol@users.noreply.github.com> Date: Sat, 3 Oct 2026 14:18:21 +0000 Subject: [PATCH 2/2] docs: address sub-DAG sharing review comments --- docs/design_docs/proposals/operator-sharing.md | 7 ------- docs/develop_docs/asap-aware-mapping-architecture.md | 9 +++------ 2 files changed, 3 insertions(+), 13 deletions(-) diff --git a/docs/design_docs/proposals/operator-sharing.md b/docs/design_docs/proposals/operator-sharing.md index f6c565c2e..1851d1809 100644 --- a/docs/design_docs/proposals/operator-sharing.md +++ b/docs/design_docs/proposals/operator-sharing.md @@ -324,13 +324,6 @@ A `Project`, for example, has one representation whether its input is an ordinar aggregate or a summary estimate. This proposal removes the representation boundary; it does not introduce rules for sharing computations across queries. -**Sub-DAG sharing** means multiple consumers reference the same operator node -and its upstream dependencies. **Common sub-DAG sharing** is the CSE step that -finds eligible, structurally identical sub-DAGs and replaces separate copies -with one shared instance. Physical planning determines how that common -computation is executed or materialized; consumers requiring different -execution phases may need separate instances. - ## 2. Node properties and why they differ Both operation categories use the `OperatorNode` declared in the §1.1 overview. diff --git a/docs/develop_docs/asap-aware-mapping-architecture.md b/docs/develop_docs/asap-aware-mapping-architecture.md index 13c7b2886..aee8fe53a 100644 --- a/docs/develop_docs/asap-aware-mapping-architecture.md +++ b/docs/develop_docs/asap-aware-mapping-architecture.md @@ -60,12 +60,9 @@ Terminology used in the diagram: realizes an operation as a concrete ASAP realization; **post-ASAP** means the resulting realization form. - A **DAG** (directed acyclic graph) represents query operators whose sub-DAGs - may be shared. **Sub-DAG sharing** means multiple consumers reference one - operator and its upstream dependencies. **Common sub-DAG sharing** is the - CSE (common subexpression elimination) step that finds eligible, structurally - identical sub-DAGs and makes them one shared instance. Rust's `Rc` - (reference-counted pointer) records that identity. Physical planning chooses - how to execute or materialize the common computation. + may be shared. See [sub-DAG sharing and ASAP-aware CSE](../design_docs/proposals/planner-layering.md#pass-2-asap-aware-common-subexpression-elimination) + for the sharing rules. Rust's `Rc` (reference-counted pointer) records + shared node identity. - A **target** is one replaceable site. A **candidate** is one valid alternative for it. `Replacement::Summary` is a constructed post-ASAP summary—maintained state such as an exact accumulator or an approximate sketch—while