Filters work based on caching bitsets to provide a fast lookup of documents that match the criteria. It looks like the query cache actually stores the hits returned from within the node. For now, it looks like query cache will not help with fetching documents (says count/aggregation/suggestions only), but when/if it does work to store search results, it's not optimized for frequent updates on the index (since that will invalidate the cache result). Filters, on the other hand, are updated aggressively by ES, so new documents get incrementally added to the bitset.
So to answer the question, they both have similar goals, but they accomplish them differently, so you will have to decide which implementation fits your needs better. On Tuesday, January 13, 2015 at 1:49:06 PM UTC-8, AndrewK wrote: > > Hallo Adrien, > > Many thanks for the clarification. > > But won't the query cache (1.4.0-Beta) > > > http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/index-modules-shard-query-cache.html > > partially "close the gap" in performance? The cache won't be as > lightweight as the filter cache (as the key is the entire JSON query rather > than a bitset and operates at shard-level), but is a cache nonetheless. > > Or am I comparing two completely different things? > > -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/8cacc807-7efb-437c-a22f-5d75f849b41c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
