Skip to content

docs: name the logical ASAP-aware optimization passes in Scenarios #538

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
zzylol merged 1 commit into from
Oct 2, 2026
Merged

docs: name the logical ASAP-aware optimization passes in Scenarios #538

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 7 additions & 7 deletions docs/design_docs/proposals/planner-layering.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1073,10 +1073,10 @@ ASAPPlanner then does automatically, and what does not change.
or batch), predictability, time selection and accuracy and latency
requirements. No code changes.

**Automatic:** the language-specific frontend converts the query. Pass 1 generates its
exact and summary candidates from the existing rules and capabilities. Pass 2
**Automatic:** the language-specific frontend converts the query. Pass 1 of logical ASAP-aware optimization generates its
exact and summary candidates from the existing rules and capabilities. Pass 2 of logical ASAP-aware optimization
checks whether it can share a summary with the queries already in the workload.
Physical planning and selection re-plan the whole workload, so adding a query can
Physical ASAP-aware optimization and plan selection re-plan the whole workload, so adding a query can
change the plan of other queries, for example when a summary becomes shared.

**Unchanged:** rules, summary families, models and every other workload entry.
Expand All @@ -1095,7 +1095,7 @@ For a function, operator or aggregate a frontend does not support yet.
answer it (Assumptions 1 and 2).
4. Its exact physical operator implementation.

**Automatic:** everything from Pass 1 onward, as for any other query.
**Automatic:** everything from Pass 1 of logical ASAP-aware optimization onward, as for any other query.

**Unchanged:** the stages, the selection rule and other queries' candidates.

Expand All @@ -1109,12 +1109,12 @@ For example, a new quantile sketch.
2. The computations it answers and the estimates it reads out.
3. Its sizing rule for an accuracy target and its error bound.
4. Whether its states can be merged, subtracted or deleted.
5. Which state fields identify it, so that equal states are shared in Pass 2.
5. Which state fields identify it, so that equal states are shared in Pass 2 of logical ASAP-aware optimization.
6. Its physical kernel: build, merge and estimate.

**Automatic:** Pass 1 offers the family wherever its declared computations
**Automatic:** Pass 1 of logical ASAP-aware optimization offers the family wherever its declared computations
appear, sizes it per query and prunes it where it cannot meet the accuracy
target. Pass 2 shares it across queries, sized for the strictest consumer.
target. Pass 2 of logical ASAP-aware optimization shares it across queries, sized for the strictest consumer.
Selection compares it with every other candidate using the deployment's models.

**Unchanged:** frontends, rewrite rules, the stages and existing queries.
Expand Down
Loading