Claude
cc73639ae5
Backlog items 4-5 close. Both-variants-in-one-run A/B at 50k, repeated with relay order reversed: every delta flipped with the order (the second-running relay won queries and ingest latency in BOTH runs), so readers=8 / mmap_size=256MiB / temp_store=MEMORY / periodic PRAGMA optimize are all noise-level on container-class hardware. The config plumbing stays (hardware-dependent, operators should measure their own box); the example config now says so explicitly. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TtDNpayEYvJH7QuPswND3A
2.0 KiB
Server-side SQLite knobs — A/B verdict: no winner on container hardware
Status: closed (negative result recorded). Backlog items 4–5 of the relay performance campaign.
What was tested
The knobs the campaign had previously reverted as noise-inconclusive, re-tested under the A/B protocol — both variants in ONE relayBench run (identical container conditions), then the run repeated with the relay order reversed to expose order bias. 50k synthetic corpus, all four knobs on the candidate at once:
[database]
readers = 8 # reader pool (default 4)
mmap_size = 268435456 # 256 MiB
temp_store_memory = true
optimize_interval_seconds = 15 # PRAGMA optimize between ingest and queries
Result
Every observed delta flipped with run order. In BOTH runs the second-running relay won most query scenarios and ingest latency — regardless of which variant it was:
- run 1 (plain → knobs): knobs won 7/10 query scenarios, better ingest p99 (8.2 vs 16.0 ms).
- run 2 (knobs → plain): plain won 6/10 query scenarios, better ingest p50/p99/throughput (8,552 vs 8,015 ev/s).
Storage size identical (±1 MiB). The periodic PRAGMA optimize also
did not move the author-archive/planner-sensitive scenarios.
Verdict
All knobs stay off by default. The [database] config plumbing
ships anyway (readers / mmap_size / temp_store_memory /
optimize_interval_seconds) because their value is hardware-dependent —
an operator on NVMe with a large page cache or a memory-constrained VPS
should measure on their own box — and optimize_interval_seconds
remains sensible operationally for long-running relays even without a
measurable win at 50k-fresh-database scale.
Do not re-benchmark these on container-class 4-core hardware without
first fixing the run-order bias: the protocol note in
quartz/plans/2026-07-03-incremental-negentropy-storage.md applies —
same-run A/B plus order reversal is the minimum, and anything that
doesn't survive the order flip is noise.