- new `residency` leg in db-bench.py driving docs/examples/residency-bench: two tables identical except the annotation, control cap + binding cap - ITS OWN PROGRAM, not a db-bench mode: declaring a resident: keys table is a WHOLE-PROGRAM constraint, so the no-WO_DATA refusal fires for every mode in the module. Putting those classes in db-bench's shared types made growth/ceiling/randread — which run without WO_DATA — refuse to start. Caught by running the leg, not by reading it - gates the RATIOS, waives the absolutes: ops/sec under a cap is swap and disk I/O and belongs to the box. Same split randread makes - rss_ratio 2.55 floor 2.0 tol 10% (structural, like bytes_per_row); overcap_vs_swap_x 1.53 floor 1.0; in_ram_cost_x 4.23 ceiling 8.0; all_collapse_x 105.4 floor 2.0 - all_collapse_x exists because the leg's FIRST run silently measured nothing: at QUICK's 40k rows a 48 MiB cap binds neither mode, so the "over-cap" half was not over cap. The cap now scales with N and the leg asserts it binds - verified the gate bites: rss_ratio 1.4, overcap_vs_swap_x 0.6 and in_ram_cost_x 12.0 are all rejected - task 7 closed: both criteria moved to Met with how each was verified Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> (cherry picked from commit a310496664982c372f51b43113465eb8ad9e9fb5)
6 lines
188 B
TOML
6 lines
188 B
TOML
name = "residency-bench"
|
|
version = "0.1.0"
|
|
description = "databasev2 2 task 7: resident: all vs resident: keys, identical tables, one annotation apart"
|
|
|
|
[runtime]
|
|
wo = ">= 0.1"
|