Skip to content

Export the AutoSketch vs ASAP evaluation table from saturation curves - #136

Merged
zzylol merged 2 commits into
mainfrom
feat/autosketch-eval-table
Oct 5, 2026
Merged

zzylol merged 2 commits into
mainfrom
feat/autosketch-eval-table

Conversation

@zzylol

@zzylol zzylol commented Oct 4, 2026 •

Copy link
Copy Markdown
Collaborator

Before this PR

The AutoSketch vs ASAPQuery evaluation (ProjectASAP/ASAPQuery#777, section 6) had no accuracy/cost table. The only one, the 18-row rqe_atomic_costs.json, measures each config at a single size, with no data-shape matching, saturation or merge evidence.

After this PR

scripts/export_autosketch_eval_table.py writes rqe-optimizer/data/autosketch-eval/table.json.

Workloads. There is one workload per dataset in ASAPQuery's skew_summary.csv:

Dataset RQEs Config rows Saturated rows
alibaba_v2022 51 1020 867
boom 20 140 47
google_2011 27 546 403

Each RQE's data parameters are the worst case over the whole dataset, rounded to the grid exactly as recommend_config.py does. Its grid rounding moved into a shared grid_point(). There is no burst variant: the whole-dataset worst cases replace AutoSketch's synthetic burst injection.

Per config. Every candidate config of every family lists:

  • autosketch_error: the single-sketch curve at max_N. AutoSketch never merges, so it has no saturation requirement.
  • asap_error_by_m for m = 1, 4, 16, 64. For CMS, CountSketch and DDSketch, every m reads the single-sketch value because they merge exactly. KLL and top-k read the merged curves from Measure accuracy after merging m shards #131.
  • saturated (max_N ≥ n_sat): ASAP may only use a value when this is true.
  • Costs from recommend_config.cost_of.

Assumptions (README, and the per-RQE assumptions field):

  • groups = 1: a key query is one sketch over its group-by keys.
  • λ = max_N / lookback.
  • An instant query's lookback is one step.
  • BOOM's N and window are derived from its 20 equal chunks per series, using the sampling step in the series name.

Inputs. KLL and top-k merged values come from #131 (merged into main as bd644fe, identical to the merged-accuracy head the curves came from). The raw curves (2.8 MB) are not committed; the README gives regeneration commands and input SHA-256s.

Validation

  • python3 scripts/test_export_autosketch_eval_table.py: 6 passed. They cover:
    • exact merge giving the same value for every m;
    • the merged KLL curve at m = 4, and the flagged fallback at m = 16;
    • the saturation flag;
    • AutoSketch reading an unsaturated value;
    • the window and label set;
    • BOOM chunk derivation.
  • python3 scripts/test_recommend_config.py: 11 passed, after the grid_point extraction.
  • Regenerated the table from the full Add saturation study: error vs N, N_saturation and Pareto value data #130 grid with cost, the 1e9 subset, and Measure accuracy after merging m shards #131's top-k and quantile merge grids. Every KLL/top-k point has a merge curve.

🤖 Generated with Claude Code

Adds scripts/export_autosketch_eval_table.py and the generated
rqe-optimizer/data/autosketch-eval/table.json (W2: alibaba_v2022, boom,
google_2011). Every config lists AutoSketch's single-sketch error at
max_N and ASAP's error after merging m = 1/4/16/64 shards, with the
saturation flag ASAP requires. recommend_config.py's grid rounding moves
into grid_point() so both scripts share it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
#131 merged into main as bd644fe with content identical to the
merged-accuracy head the merge curves came from, so drop the
not-merged caveat. The table and its recorded revision are unchanged.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@zzylol
zzylol merged commit 964ccb5 into main Oct 5, 2026
2 checks passed
zzylol added a commit that referenced this pull request Oct 5, 2026
Runner (examples/autosketch_vs_asap.rs) for the traces workloads of
ProjectASAP/ASAPQuery#777: ASAP (joint MILP with one absolute latency SLA
per sweep point), PerQuery-CostAware and AutoSketch-Adapted, scored by
objectives::score and priced per EC2 family, with sanity checks.

Accuracy now depends on the query's merge count m = S/x: a cost entry may
carry "{metric}@m{b}" keys, eligibility reads the smallest measured b >= m,
and a merge larger than every measured b is ineligible.

Results for Alibaba 2022, Google 2011 and BOOM with figures and summary.
The earlier example and scaling workloads are dropped (#777 §6).

Rebased onto main, which now has #137, #135 and #136.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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