Skip to content

v3: no hm+bf text domain — text_search requires the ORE term, capping eq+match string ingest at ORE speed (−87% vs v2) #355

Description

@coderdan

Problem

The only v3 text domain carrying both equality (hm) and match (bf) capability is text_search, whose CHECK also requires the ORE term (ob). A v2 unique+match column migrating to v3 must therefore start generating ORE terms client-side, capping string ingest at ORE-generation speed:

Config Throughput (10k batch)
v2 unique+match 9,649 rec/s
v3 text_search (unique+match+ore) 1,278 rec/s (−87%)

Rows are also correspondingly wider. For comparison, other v3 ingest paths are at parity with v2 (int ORE ±2%; conversion + domain-CHECK overhead measured ≈ 0), so this is entirely the extra term.

Proposal

Add an hm+bf domain to the catalog (e.g. text_eq_match) for the common "exact lookup + pattern match, no ordering" column — or explicitly document the ORE cost as an accepted trade-off of the v3 type system. Note the catalog currently has no [Hm, Bloom] entry and from_v2 fails closed on a missing ob, so there is no workaround from the consumer side.

Evidence

report/V3_COMPARISON.md ingest table and results/ingest/v3/encrypt_string_v3_combined.json on cipherstash/benches#23 (numbers re-verified under cipherstash-client 0.38.1).

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Fields

No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions