Repository navigation
docs(storage): state the count cap cost as a decode per key past it - #1137
Priyanshubhartistm wants to merge 4 commits into
Conversation
Signed-off-by: Priyanshubhartistm <bhartipriyanshustm@gmail.com>
🦋 Changeset detectedLatest commit: cb6a70a The changes in this PR will be included in the next version bump. This PR includes changesets to release 0 packagesWhen changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the
|
[Low impact] The PR appears safe to merge; it changes only documentation and comments.
|
Signed-off-by: Priyanshubhartistm <bhartipriyanshustm@gmail.com>
… one Signed-off-by: Priyanshubhartistm <bhartipriyanshustm@gmail.com>
Dismissed because a newer commit was pushed; Greptile will re-review the current head.
Description
ADR 0011 and the comments in
crates/nostream-storage/src/lmdb/events.rsstate the cost of the count's id-set cap wrongly: they say it is "a body decode per repeated key past it". The code reads the row's body for every key the set does not answer past the cap, unless the range is the family's first exact criterion, so the cost is not confined to repeated keys.This PR corrects the prose in four places in the ADR and three comments in
events.rs. It changes no code and no behaviour:#gprefix's key), not only a repeated one, and gives the measured cost (5.3× to 5.7× the uncapped walk at 20,000 rows), using the wording the issue proposes.tagfield comment, theshortcut:marker and the test's doc comment.What the issue says is right is left as it is: the set bound (270 352 B), the exactness of the count and the free cap below 5,000 rows.
Related Issue
Fixes #1081
Motivation and Context
The record is wrong in the direction a reader would trust: a reader who believes the cost is per repeated key would expect a filter with no repeated key to pay nothing past the cap, while
{"#t":["zz","a"]}(one key a row, zero repeats) costs 5.7× its uncapped time at 20,000 rows.How Has This Been Tested?
Prose and comment changes only. The Rust validation commands pass (
cargo fmt --all --check, both clippy passes,cargo test --workspace --all-features,cargo build --workspace --all-features --release), and the diff touches no code line.Screenshots (if appropriate):
Types of changes
Checklist: