Skip to content

refactor(types): nest SketchAlgorithm+SketchParams inside SketchKind - #266

Closed
zzylol wants to merge 2 commits into
feat/replacement-strategy-251from
refactor/sketch-kind-algorithm-nesting
Closed

zzylol wants to merge 2 commits into
feat/replacement-strategy-251from
refactor/sketch-kind-algorithm-nesting

Conversation

@zzylol

@zzylol zzylol commented Aug 23, 2026

Copy link
Copy Markdown
Contributor

Split out of #259 per zzylol's review comment on replacement.rs:275 — this is a genuinely separate concern (type-system restructuring) from #259's ReplacementStrategy/TargetSubDAG work, so it's its own PR, stacked on top of #259 (base branch is feat/replacement-strategy-251, not main — merge #259 first).

What

Aligns the type system to a real three-level nested structure — family → kind → algorithm — instead of a flat (algorithm, params) pair on SummaryFamilyType::Sketch:

SummaryFamilyType::Sketch(SketchKind)
SketchKind::Quantile(SketchAlgorithm, SketchParams)  // + Cardinality/Frequency/TopK
Implementation::Sketch(SketchKind)  // mirrors SummaryFamilyType's shape
  • SummaryFamilyType (family) — unchanged: Sketch, Sample, Wavelet, StatModel, ExactAggregate.
  • SketchKind (kind) — new: Quantile/Cardinality/Frequency/TopK, each variant carrying the committed (SketchAlgorithm, SketchParams) — a SketchKind value is never just "some quantile sketch," it always already names which one.
  • SketchAlgorithm (algorithm) — renamed from the old flat SketchKind: Kll/DDSketch/Hll/etc.

SketchKind::new(algorithm, params) is the one place (SketchAlgorithm, SketchParams) gets classified into the right variant; .algorithm()/.params() get the pair back out regardless of variant.

SketchFamilyStrategySketchAlgorithmStrategy, ForceSketchKindForceSketchAlgorithm — it only ever enumerates algorithms within an already-fixed family+kind, never chooses between families (that's unbuilt future work, no ReplacementStrategy does it yet).

Also

Implementation::Sketch restructured the same way, which simplifies bind.rs's Implementation -> SummaryFamilyType conversion for the sketch case to a straight pass-through instead of destructuring and rebuilding a pair.

Updated every construction/destructuring site across asap-aware-mapping and integration-tests, plus the dev guide's family/kind/algorithm section.

Checks

cargo build/test/fmt/clippy --workspace all pass clean; cargo doc introduces no new broken-link warnings.

🤖 Generated with Claude Code

@zzylol
zzylol force-pushed the refactor/sketch-kind-algorithm-nesting branch from 7ed5345 to e609c86 Compare August 23, 2026 19:57
@zzylol
zzylol force-pushed the feat/replacement-strategy-251 branch from ca60c0c to 66c772d Compare August 23, 2026 19:59
@zzylol
zzylol force-pushed the refactor/sketch-kind-algorithm-nesting branch 5 times, most recently from fa72c44 to e1a9296 Compare August 24, 2026 02:47
…thm (SketchAlgorithm)

Rebuilt on top of feat/replacement-strategy-251's latest tip (the
bind::implement_tree/_with deletion). Same split as before: SketchKind
becomes a nested category type (Quantile/Cardinality/Frequency/TopK,
each wrapping a committed (SketchAlgorithm, SketchParams) pair) with
SketchAlgorithm holding the old flat variant list (Kll/Cms/Hll/
DDSketch/CmsWithHeap/Kmv/Theta/CountSketch/CountSketchWithHeap).
SketchKind::new(algorithm, params) is the one classifier; .algorithm()/
.params() extract the committed pair back out.

SketchFamilyStrategy renamed to SketchAlgorithmStrategy throughout, to
free up "family" to mean what SummaryFamilyType names (Sketch/Sample/
Wavelet/StatModel/ExactAggregate) and "kind" to mean the new
sub-family category, keeping "algorithm" for the concrete realization.

Implementation::Sketch and SummaryFamilyType::Sketch both collapse
from a (kind, params) pair to a single SketchKind field, since a
SketchKind already carries its own committed (algorithm, params).

Reapplied by hand against the current tree rather than via rebase/
cherry-pick (a prior rebase across these same overlapping renames
silently dropped hunks without conflict markers) — guided by
`git diff` against the previous build of this branch to find every
site, then verified end to end.

Verified: cargo build --workspace --all-targets, cargo test
--workspace (0 failures), cargo fmt --all -- --check, cargo clippy
--workspace --all-targets --all-features -- -D warnings — all clean.
@zzylol
zzylol force-pushed the refactor/sketch-kind-algorithm-nesting branch from e1a9296 to 583112d Compare August 24, 2026 12:47
…diom

A reader asked what the diagram's "a caller wanting one answer:
replacements(...).into_iter().next()" line actually does — spell it
out inline instead of assuming it's self-evident.
zzylol added a commit that referenced this pull request Aug 24, 2026
…thm (SketchAlgorithm) (#266, part of #33)

Absorbs PR #266 (refactor/sketch-kind-algorithm-nesting) into this branch —
#266 was last rebased on a much older tip and this branch's own code has
since changed enormously (implementation.rs/bind.rs merged into
replacement.rs, SummaryExpr::Logical -> KeepPreAsap, search.rs/PlanSpace
merged in, bind.rs deleted), so #266's diff was read and manually reapplied
against the current surface rather than merged/rebased/cherry-picked.

Restructures the sketch type system into a real three-level nesting —
family -> kind -> algorithm — instead of a flat (algorithm, params) pair:

    SummaryFamilyType::Sketch(SketchKind)
    SketchKind::Quantile(SketchAlgorithm, SketchParams)  // + Cardinality/Frequency/TopK
    Implementation::Sketch(SketchKind)                   // mirrors SummaryFamilyType's shape

- `SketchAlgorithm` — the old flat `SketchKind` enum (Kll/Cms/Hll/DDSketch/
  CmsWithHeap/Kmv/Theta/CountSketch/CountSketchWithHeap), renamed verbatim —
  the actual concrete algorithm choice.
- `SketchKind` — new nested enum (Quantile/Cardinality/Frequency/TopK), each
  variant carrying the committed `(SketchAlgorithm, SketchParams)` pair — a
  `SketchKind` value always already names which concrete algorithm, never
  "some quantile sketch, algorithm TBD". `SketchKind::new(algorithm, params)`
  is the one place a pair gets classified into its category; `.algorithm()`/
  `.params()` extract the pair back out regardless of variant.
- `SummaryFamilyType::Sketch(SketchKind, SketchParams)` collapses to
  `Sketch(SketchKind)`; `Implementation::Sketch { kind, params }` becomes the
  tuple variant `Sketch(SketchKind)`.
- `SketchFamilyStrategy` -> `SketchAlgorithmStrategy` — it only ever
  enumerates algorithms within an already-fixed family+kind, never chooses
  between families/kinds (unbuilt future work, no ReplacementStrategy does
  that yet). `ForceSketchKind` no longer exists on this branch (already
  deleted during this session's earlier ReplacementStrategy/binding-unification
  work), so its rename to `ForceSketchAlgorithm` doesn't apply.
- `CostModel::rank_candidates`/`size_params` now take/return `SketchAlgorithm`
  (they operate one level below `SketchKind`, on the concrete algorithm
  choice within an already-fixed kind); `sketch_kind_of` (the PlanSpace
  ranking helper added when search.rs merged into replacement.rs) likewise
  extracts `.algorithm()` for `CostModel::rank_candidates` comparisons.

Updated every construction/destructuring site across `replacement.rs`,
`cost_model.rs`, `lib.rs`, `crates/devtools`, `crates/frontend-promql`'s
observability corpus test, and `crates/integration-tests`' l4_binding(_sql)
and cse tests — not just `asap-aware-mapping`, per #266's own scope but
against the current, much larger merged surface. Dev guide gets the
"Family, kind, and algorithm" section from #266 plus the same
family/kind/algorithm terminology pass across the rest of the guide and the
user guide.

Verified: cargo build/test/fmt/clippy --workspace all clean.

PR #266 (refactor/sketch-kind-algorithm-nesting) is now superseded by this
commit and should be closed.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@zzylol

zzylol commented Aug 24, 2026

Copy link
Copy Markdown
Contributor Author

Superseded — its content (SketchKind/SketchAlgorithm nesting) was folded directly into #259 (feat/replacement-strategy-251) rather than staying a separate stacked PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant