# Block-max WAND URL: /docs/concepts/block-max-wand The query pruning strategy Tachyon uses for multi-term search — same top-K results, less work. Block-max WAND (Weak AND) is the query execution strategy Tachyon uses for multi-term search: it skips postings blocks that provably cannot rank highly enough to matter, without changing which documents end up in the results. ## The problem it solves [#the-problem-it-solves] A naive multi-term query scores every candidate document — every document containing at least one query term — fully, then sorts and keeps the top K. That's correct, but wasteful once postings lists get long: most candidates were never going to make the top K, and scoring them anyway costs real work for nothing. ## How it works [#how-it-works] Postings are stored in fixed-size blocks, each carrying per-block skip metadata — notably the maximum term frequency any document in that block achieves for that term (see [Inverted Index](/docs/concepts/inverted-index) for the on-disk layout). From that maximum, a cheap-to-compute **upper bound** on the best possible BM25 contribution any document in the block could score for that term follows directly. Summing the per-term upper bounds for a block across all query terms gives an upper bound on the best possible combined score anything in that block could achieve. If that upper bound doesn't beat the lowest score currently sitting in the top-K, the entire block is skipped — no decoding, no per-document scoring. ## Why the results don't change [#why-the-results-dont-change] This is what separates pruning from approximation: the skipped blocks are mathematically proven incapable of affecting the outcome, not heuristically unlikely to. The ranked top-K produced with block-max WAND pruning is identical to the one a full, unpruned scoring pass would produce — same candidates, same scores, same order. See [Relevance & BM25](/docs/relevance-bm25) for the scoring function this bounds. ## When it pays off [#when-it-pays-off] The savings scale with postings-list depth and term-frequency skew. A query combining a rare term with a very common one is the clearest case: the common term's postings list is long, but once the top-K fills with strong matches, large stretches of the common term's postings can be skipped without ever being decoded, because their maximum possible contribution can't compensate for not matching the rare term at all. For short queries against small collections, there isn't enough postings-list depth for pruning to matter much. It earns its keep on multi-term queries against large, skewed collections — the common case for real production search traffic. See [Architecture → Query Pipeline](/architecture#query-pipeline) for where this sits in the full request path, from parsing through to the ranked response.