# Precedence of Query Filters in ES 2.x

**URL:** <https://discuss.elastic.co/t/precedence-of-query-filters-in-es-2-x/49583>\
**Category:** Elasticsearch\
**Created:** [May 9, 2016, 7:52pm UTC](https://discuss.elastic.co/t/precedence-of-query-filters-in-es-2-x/49583 "2016-05-09T19:52:57Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![marinoc](https://avatars.discourse-cdn.com/v4/letter/m/87869e/32.png) [@marinoc](https://discuss.elastic.co/u/marinoc)\
**Post date:** [May 9, 2016, 7:52pm UTC](https://discuss.elastic.co/t/precedence-of-query-filters-in-es-2-x/49583/1 "2016-05-09T19:52:57Z")

</div>

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?

Thanks!

---

<div class="post-metadata">

**Author:** ![polyfractal](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/polyfractal/32/48162_2.png) [@polyfractal](https://discuss.elastic.co/u/polyfractal)\
**Post date:** [May 10, 2016, 4:13pm UTC](https://discuss.elastic.co/t/precedence-of-query-filters-in-es-2-x/49583/2 "2016-05-10T16:13:36Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![marinoc](https://avatars.discourse-cdn.com/v4/letter/m/87869e/32.png) [@marinoc](https://discuss.elastic.co/u/marinoc)\
**Post date:** [May 10, 2016, 4:27pm UTC](https://discuss.elastic.co/t/precedence-of-query-filters-in-es-2-x/49583/3 "2016-05-10T16:27:59Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![polyfractal](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/polyfractal/32/48162_2.png) [@polyfractal](https://discuss.elastic.co/u/polyfractal)\
**Post date:** [May 10, 2016, 4:35pm UTC](https://discuss.elastic.co/t/precedence-of-query-filters-in-es-2-x/49583/4 "2016-05-10T16:35:49Z")

</div>

Oops, sorry, I should have explained a bit more. 🙂

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.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 5, 2017, 10:52pm UTC](https://discuss.elastic.co/t/precedence-of-query-filters-in-es-2-x/49583/5 "2017-07-05T22:52:40Z")

</div>


