# The queries for numeric fields are slower after upgraded the cluster from 2.4.5 to 5.6.3

**URL:** https://discuss.elastic.co/t/the-queries-for-numeric-fields-are-slower-after-upgraded-the-cluster-from-2-4-5-to-5-6-3/121620
**Category:** Elasticsearch
**Created:** [February 27, 2018, 9:35am UTC](https://discuss.elastic.co/t/the-queries-for-numeric-fields-are-slower-after-upgraded-the-cluster-from-2-4-5-to-5-6-3/121620 "2018-02-27T09:35:25Z")
**Posts on this page:** 1
**Showing post:** 2

<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: [March 2, 2018, 5:29pm UTC](https://discuss.elastic.co/t/the-queries-for-numeric-fields-are-slower-after-upgraded-the-cluster-from-2-4-5-to-5-6-3/121620/2 "2018-03-02T17:29:33Z")

</div>

> [@Zzzxf](#):
>
> Is it due to the changing of numeric data-structure in 5.0? Can I reindex the field as keyword to solve?

Basically, yes.

In ES 5.x, numerics use a new datastructure (BKD tree). This allows better compression, faster numeric operations and lower memory usage... but it is not ideal for "point lookups" like a `term` query. E.g. it is designed for numeric style operations like ranges, but not single value lookups.

If that field is only used for exact-match lookups, you can re-index it as a `keyword`. Keyword fields are optimized for exact-match lookups and will be a lot faster.

More info: [Tune for search speed | Elasticsearch Guide [master] | Elastic](https://www.elastic.co/guide/en/elasticsearch/reference/master/tune-for-search-speed.html#_map_identifiers_as_literal_keyword_literal)

To dive a bit more into technicals, the BKD datastructure doesn't support sorted iteration, so it has to collect all matches, sort the array and then return an iterator to that sorted array (paraphrasing). That process happens during the `build_scorer` step. This process isn't bad when dealing with numeric ranges since the cost is amortized over all the values that are being iterated over, but can get expensive when asking for a bunch of individual points.

2.x didn't have BKD trees, hence the difference in performance.

---

_[View the full topic](https://discuss.elastic.co/t/the-queries-for-numeric-fields-are-slower-after-upgraded-the-cluster-from-2-4-5-to-5-6-3/121620)._