chore(deps): bump zigstore to v1.2.0#9
Merged
Conversation
Adopt the v1.2.0 multi-writer (ShardSet) release. Verified compatible with dmozdb: zig build test green, builds clean in ReleaseFast. Benchmarked against the v1.1.0 baseline (same 1000-cat/50k-link fixture) — read and write paths are flat within run-to-run noise (create_link ~294k vs ~328k ops/s, both inside the measured variance band; get_link, mixed, browse, search all unchanged). No write-throughput change because dmozdb does not adopt ShardSet: it remains a single zigstore.Engine(schema) store with one WAL writer. ShardSet is left unused by design — dmozdb is fsync-bound on a single disk (where ShardSet regresses to ~0.71x), and keyspace partitioning would break the atomic dual-index writes, whole-keyspace subtree scans, and globally-unique id invariants the directory depends on. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
poly-glot
added a commit
that referenced
this pull request
Jul 4, 2026
Adopt the v1.2.0 multi-writer (ShardSet) release. Verified compatible with dmozdb: zig build test green, builds clean in ReleaseFast. Benchmarked against the v1.1.0 baseline (same 1000-cat/50k-link fixture) — read and write paths are flat within run-to-run noise (create_link ~294k vs ~328k ops/s, both inside the measured variance band; get_link, mixed, browse, search all unchanged). No write-throughput change because dmozdb does not adopt ShardSet: it remains a single zigstore.Engine(schema) store with one WAL writer. ShardSet is left unused by design — dmozdb is fsync-bound on a single disk (where ShardSet regresses to ~0.71x), and keyspace partitioning would break the atomic dual-index writes, whole-keyspace subtree scans, and globally-unique id invariants the directory depends on.
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
1 participant
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.
Adopt the zigstore v1.2.0 multi-writer (ShardSet) release.
Compatibility
zig build test→ exit 0dmozdb+benchbuild clean in ReleaseFastbuild.zig.zonchanges (url + hash), mirroring the v1.1.0 bump (chore(deps): bump zigstore to v1.1.0 #8)Benchmark: v1.2.0 vs v1.1.0 (same 1000-cat / 50k-link fixture, median-of-3 on write paths)
All deltas are within run-to-run noise.
create_link's −10% sits inside the measured 294k–328k variance band.Why no write-throughput change — and why that's correct
dmozdb does not adopt
ShardSet; it stays a singlezigstore.Engine(schema)store with one WAL writer. The bump only makes the type available. Adopting ShardSet is left out by design:architecture.md): atomic dual-index writes (links_by_id+link_by_categoryare different keys → different shards → atomicity lost), whole-keyspace subtree range scans (op-17, the slice-6 path), and globally-unique ids (per-shard counters).The right lever for write throughput here is group commit (amortize the fsync), not horizontal sharding.
🤖 Generated with Claude Code