The index.queries.cache.enabled setting in Elasticsearch controls whether the query cache is enabled for a specific index. The query cache stores the results of filter clauses, allowing for faster retrieval when the same filter is used in subsequent queries.
- Default Value:
true - Possible Values:
trueorfalse - Recommendations: Keep enabled for indices with frequently repeated filter clauses. Disable for indices where filters are rarely reused or data changes very frequently.
The query cache is particularly effective for filter contexts in bool queries and certain aggregations. Unlike the request cache which stores entire search results, the query cache stores individual filter clause results, making it more granular and reusable across different queries that share the same filters.
Example
To disable the query cache for an index named "my_index":
PUT /my_index/_settings
{
"index.queries.cache.enabled": false
}
You might want to change this setting if:
- Your index has highly unique filter patterns with minimal reuse.
- You're experiencing excessive memory pressure from caching.
- Data freshness is critical and even briefly cached filter results are unacceptable.
Common Issues and Misuses
- Disabling the cache for indices with repetitive filter patterns, losing significant performance gains.
- Enabling the cache when filter clauses are almost always unique, wasting memory.
- Not coordinating this setting with the cluster-wide
indices.queries.cache.sizesetting.
Do's and Don'ts
Do's:
- Enable for indices with frequently reused filter clauses (e.g., status filters, date ranges).
- Monitor cache statistics to verify the cache provides value.
- Consider disabling for write-heavy indices where filters change constantly.
Don'ts:
- Don't disable without measuring the performance impact first.
- Don't forget that this is an index-level setting that works in conjunction with cluster-level cache size.
- Don't assume disabling saves significant memory unless you've verified high eviction rates.
Frequently Asked Questions
Q: How does the query cache differ from the request cache?
A: The query cache stores results of individual filter clauses, while the request cache stores entire search responses. Query cache is more granular and can be reused across different queries sharing the same filters.
Q: Can I control caching for specific queries?
A: Yes, you can use the ?request_cache=false parameter to bypass caching for specific requests, though this primarily affects the request cache. Individual filter clauses will still use the query cache if enabled.
Q: What types of queries benefit most from the query cache?
A: Filter contexts in bool queries, terms filters, range filters on dates or numbers, and filters used in aggregations benefit most. Queries with scoring (query context) don't use the query cache.
Q: How is the query cache invalidated?
A: Cache entries are automatically invalidated when the index is refreshed and the data changes. The cache uses segment-level caching, so entries are invalidated when segments are merged or updated.
Q: Does enabling this setting consume significant memory?
A: Memory usage depends on filter complexity and reuse patterns. The actual memory is controlled by the cluster-level indices.queries.cache.size setting, which defaults to 10% of heap.
