Precedence of Query Filters in ES 2.x

Are filters in ES 2.x still applied based on the order they appear in the query? Is it still best practice to place the more restrictive filters (those that will return fewer records) first?


Nope, query/filter order in ES 2.x doesn't matter. With the one exception of filters in the function_score query, which can optionally be applied "in order".

Note: the ordering behavior in ES 1.x just applied to and/or/not queries, the rest were order agnostic as well.

Thanks, Zachary.

So does ES 2.x have any logic to apply filters in the most efficient manner (i.e. return smallest subset first), or is it truly random?

Oops, sorry, I should have explained a bit more. :slight_smile:

Lucene (and by proxy, Elasticsearch) has heuristics to estimate the "cost" of a query. These heuristics include things like how exclusive the query is, how intrinsically expensive the calculation is (e.g. a term comparison is a lot faster than calculating a geo distance comparison), some queries have a "fast" estimation mode followed by a slower "precise" mode, etc.

It then re-orders the queries to optimize execution. That could mean running the least expensive ones first, or potentially running a more expensive but highly selective one to cut down other query evaluations.

Also note that it's a bit tricky, since one query doesn't "run to completion" before the next start. Queries in Lucene have a "leap frog" behavior where they take turns advancing their iterators. Matches are recorded where all the iterators line up. So much of the reordering optimization is around which iterators to execute first, since the more they can skip the less the downstream iterators need to evaluate.