eval: select measured ERP configurations for Top-K dashboards - #602
Open
zzylol wants to merge 10 commits into
Open
eval: select measured ERP configurations for Top-K dashboards#602zzylol wants to merge 10 commits into
zzylol wants to merge 10 commits into
Conversation
zzylol
marked this pull request as draft
September 10, 2026 21:13
zzylol
marked this pull request as ready for review
September 10, 2026 21:44
fix(eval): measure CPU time in Top-K ERP resources
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The dashboard comparison used hardcoded ERP parameters, so its memory and planning-time results did not test ERP selection. The original results also had event-order, query-endpoint and exact-retention accounting errors.
What
How
The offline backend window benchmark adapter emits sketch-bench ERP-v1-compatible records with per-window Recall loss. Synthetic profile seeds are independent of evaluation seeds. Custom profiling only reads calibration data; its cold-start construction cost is reported separately. Planner filters measured accuracy and selects minimum retained-memory configurations. Missing evidence goes to an explicitly labeled exact fallback because a frequency additive-error bound does not certify Top-K recall.
Before this PR
The ERP arm always selected CMS 5×512 with heap 32; the reported microsecond planning time timed a hardcoded filter. The raw v1 results are withdrawn and remain available only in git history.
After this PR
Changing a profile's measured error changes the selected configuration; oversized deployments are rejected. ERP can choose shared or independent configurations, with selected record IDs, match distance and composed costs recorded. All baselines answer windows ending at panes 121–220.
Completed release-mode measurements (median retained logical memory):
Synthetic ERP retains about 26% less memory. Google selects identical configurations and does not establish SLA compliance; its calibration evidence is insufficient to guarantee held-out accuracy. No thresholds were tuned on held-out results to hide this failure.
The evaluation report includes workload/query/data definitions, planning time for every baseline, separate profile-construction costs, update/merge/readout measurements, and figures. Adjacent committed files contain raw results, measured profiles, replay data, and provenance. Google trials repeat the same trace for timing, not independent statistical evidence.
Verification
Scope
The adapter produces measured window-conditioned ERP evidence; it does not invoke the sketch-bench executable. The benchmark calls the real Planner ERP selector, not the full production compiler. Arbitrary pane-width search, production drift handling and RSS accounting remain outside this implementation. Memory uses a common retained-payload proxy; timings are wall-clock measurements. The Google evaluation remains the explicitly identified sparse 1,971-event interval from one shard. Accuracy failures will be reported as failing points, not accuracy-equivalent wins.