Which parts of an Elasticsearch bool query can the node query cache accelerate?

## What the cache is The node query cache is a per-node structure shared by all shards allocated to that node. It maps a query to a **per-segment set of matching document ids** — in Lucene terms, a cached `DocIdSet`, often a compressed bitset. On a hit, the clause does not touch postings at all: the engine intersects the cached set with the rest of the query. Its size is bounded by the static node setting `indices.queries.cache.size`, expressed as a percentage of heap; because it is static, changing it requires a node restart. It can be disabled per index with `index.queries.cache.enabled`. ## Why only filter context A clause in query context must answer "how well?" per document, and that answer is a float that depends on the query terms, field norms and collection statistics. There is nothing compact and reusable to store. A clause in filter context answers "yes or no", which for a segment is exactly a set of doc ids — small, compressible and reusable across every request that asks the same question. That is the whole reason "move it to `filter`" is standard advice: it is not only about skipping score arithmetic, it is about making the clause *cacheable at all*. Eligible: `bool` `filter`, `bool` `must_not`, the inner query of `constant_score`, and clauses nested inside those. Not eligible: `bool` `must`, `bool` `should`, `dis_max` sub-queries, the `positive` and `negative` sides of a `boosting` query. ## The caching policy — why a filter can be eligible and still not cached Eligibility is not admission. Lucene applies a usage-tracking policy: a query has to be seen repeatedly before its result is worth materialising, and *cheap* queries are deliberately never cached because re-executing them costs less than storing and looking them up — a simple `term` query on a keyword field is the canonical example. Costlier shapes, such as multi-term queries and numeric or date range queries over points, are the real beneficiaries. There is also a segment-size heuristic: caching is skipped on small segments, because tiny segments are cheap to scan and are likely to be merged away soon, wasting the entry. So the honest answer to "why is my filter not cached?" has three branches: it is not in filter context; it is in filter context but too cheap or too infrequent for the policy; or it is never the *same* query twice. ## The date-math trap The third branch is the one that bites in production. Dashboards and alerting queries almost always carry a time window: ```json { "range": { "@timestamp": { "gte": "now-1h" } } } ``` `now` resolves to the current millisecond at execution, so every request produces a *different* range query. It is eligible, it is expensive enough to be worth caching, and it never hits, because the key is new each time. Rounding fixes it: ```json { "range": { "@timestamp": { "gte": "now-1h/m" } } } ``` Now the lower bound is identical for a whole minute and every request in that minute can reuse the entry. Rounding to the hour or day widens the reuse window further at the cost of window precision. A common production shape splits the range in two: a rounded, cacheable clause covering the bulk of the window plus a small unrounded clause covering the recent tail. ## Invalidation is a non-event Because Lucene segments are immutable, a cached entry for a segment can never go stale — a newly indexed document lands in a new segment, which simply has no entry yet and is evaluated normally. Entries are dropped when their segment disappears in a merge, and evicted under LRU pressure when the cache is full. There is no invalidation logic to reason about, which is a genuinely nice property to be able to state in an interview. The consequence for write-heavy indices is that new segments arrive constantly, so a share of every query is always uncached; heavy refresh rates therefore reduce effective hit ratios, and a very low `refresh_interval` costs more than just merge pressure. ## Not the same as the other caches Elasticsearch has more than one cache and mixing them up is a classic interview stumble. The node query cache described here caches *clause results per segment*. The shard request cache is a different mechanism at a different granularity, and field data structures for sorting and aggregations are different again. If asked, name the node query cache precisely and say it caches filter-clause doc-id sets. ## What to do with this in practice 1. Put every exact-value predicate in `filter` or `must_not`. 2. Round date math so the filter text repeats. 3. Keep filter clauses *stable* across requests — build them from a small, enumerable set of shapes rather than from freely-varying user input, so the same handful of filters recur across all users. 4. Do not expect a plain `term` filter to show cache benefit; its win is skipping scoring, not caching.