nx_segbloom.nx

nx_segbloom.nx -- EVIDENCE FIRST: does a per-segment TERM BLOOM actually skip enough segments to be worth wiring into the hot search path? MEASURES ONLY. It writes nothing, changes no live code and touches no existing call site -- because the honest order is prove-the-win, then wire it. THE DEFECT IT TARGETS (measured 2026-08-06): /api/search costs a FIXED ~6.6s even for a query that matches ZERO documents, against a 42ms control on the same daemon. ss_term (nx_seg_store:2441) walks EVERY live segment and calls ss_terms_find on that segment's mmap'd terms block: while s < ns { let tb = h[5+8*s]; ss_terms_find(tb, h[6+8*s], term, outs) ... } The blocks are already mapped, so the cost is ONE PAGE FAULT PER SEGMENT -- ~896 segments x ~8ms. A resident bloom per segment answers "definitely not here" without touching the mapping at all, so the fault never happens. Segments are IMMUTABLE in an append-only store, which is what makes this sound: a per-segment term bloom is computed once and can never go stale. REUSE, NOT REINVENTION: the bloom is nx_sketch_bloom (v2, murmur3 + Kirsch-Mitzenmacher double hashing, already used in production by nx_ingest_runner) and the bits/item + k constants are the pre-computed FPR breakpoints from nx_bloom_capacity. Nothing here is a new filter. nx_segbloom stat <domain> [maxsegs] nx_segbloom probe <domain> <profile 1=10pct|2=1pct> <term> [maxsegs] license_tier: ORIGINAL No hw writes (Rule 26). expect_exit: 0