Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Query DSL: Fine grained filter caching control with sensible defaults #424

Closed
kimchy opened this issue Oct 12, 2010 · 1 comment
Closed

Comments

@kimchy
Copy link
Member

kimchy commented Oct 12, 2010

A more fine grained control over filters and if they should be cached or not. Caching a filter basically means building a fast in memory lookup of doc_id -> bit (0 does not match, 1 match). For some filters, it make sense to default to cache them, and some not. All allow to change the default behavior by setting _cache to either true or false.

The following filters are cached by default: prefix, term, terms, range.

The following filters are not cached by default: and, bool, fquery, geo_bounding_box, geo_distance, geo_polygon, not, or, script.

The ones that are not cached are already either fast since they work against cached field data, or the chances of executing the same filter are low enough that it does not make sense to default it.

There are cases though where it does make sense to cache it. For example, executing a common filter for distance from a certain point should enable caching.

@kimchy
Copy link
Member Author

kimchy commented Oct 12, 2010

Query DSL: Fine grained filter caching control with sensible defaults, closed by 8a8a4d6.

medcl pushed a commit to medcl/elasticsearch that referenced this issue Jul 1, 2011
costin pushed a commit that referenced this issue Dec 6, 2022
🤖 ESQL: Merge upstream
emilykmarx pushed a commit to emilykmarx/elasticsearch that referenced this issue Dec 26, 2023
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant