Practical Elasticsearch Filter Context Cases: When It Speeds Up Queries and When It Doesn't

Knowledge Background

Elasticsearch documentation often recommends using filter clauses to avoid scoring calculations and to take advantage of query‑cache mechanisms.

For detailed background on filter caching see the earlier blog post "Elasticsearch Filter Cache Acceleration Details".

Ordinary Case

In the first example a range query on the date field is executed with the clause placed in must. After clearing the cache, the query is run five to ten times and the cache statistics are inspected.

# Clear cache
POST indexname/_cache/clear?query=true
# Execute query 5‑10 times
GET indexname/_search
{
  "query": {
    "bool": {
      "must": [
        {
          "range": {
            "date": {
              "gte": "2024-01-01",
              "lte": "2024-03-01"
            }
          }
        }
      ]
    }
  }
}
# Check cache status
GET indexname/_stats?human=true&filter_path=*.*.query_cache

The query_cache size and count remain zero, indicating no cache usage, and query latency stays around 900‑1100 ms.

Repeating the test with the same range condition moved to a filter clause:

# Clear cache
POST indexname/_cache/clear?query=true
# Execute query 5‑10 times
GET indexname/_search
{
  "query": {
    "bool": {
      "filter": [
        {
          "range": {
            "date": {
              "gte": "2024-01-01",
              "lte": "2024-03-01"
            }
          }
        }
      ]
    }
  }
}
# Check cache status
GET indexname/_stats?human=true&filter_path=*.*.query_cache

Repeated executions now show a noticeable speed increase, and the cache statistics display non‑zero size and count, confirming that the filter context engaged the query cache.

Usage Pitfalls

Not every filter automatically speeds up queries. The article presents a second scenario using a terms query on the idno field, first with a must clause and then with a filter clause.

GET indexname/_search
{
  "query": {
    "bool": {
      "must": [
        { "terms": { "idno": ["2024001Q0001235681","2024001Q0002356812","2024001Q0008197301","2024001Q0002817617"] } }
      ]
    }
  }
}

and

GET indexname/_search
{
  "query": {
    "bool": {
      "filter": [
        { "terms": { "idno": ["2024001Q0001235681","2024001Q0002356812","2024001Q0008197301","2024001Q0002817617"] } }
      ]
    }
  }
}

Both queries, after multiple runs, exhibit similar latency and both generate query‑cache activity. The article explains that Elasticsearch implicitly rewrites the must query into a ConstantScore query, which is treated as a filter‑context query and therefore also benefits from the cache.

Verification Approach

To confirm cache usage, the article suggests checking the cache statistics via:

GET indexname/_stats?human=true&filter_path=*.query_cache

For deeper analysis of whether a query has been transformed into a filter‑friendly form, the explain API can be used:

GET indexname/_search
{
  "explain": true,
  "query": {
    "bool": {
      "filter": [
        { "terms": { "idno": ["2024001Q0001235681","2024001Q0002356812","2024001Q0008197301","2024001Q0002817617"] } }
      ]
    }
  }
}

The response reveals whether the underlying query method is ConstantScore and whether scoring has been eliminated, confirming filter‑context execution.

Additionally, the article mentions using the INFINI Console tool for visual monitoring of cache metrics within the index‑advanced monitoring charts.