# Slow performance after upgrade from 2.4 **URL:** https://discuss.elastic.co/t/slow-performance-after-upgrade-from-2-4/128774 **Category:** Elasticsearch **Created:** [April 19, 2018, 10:15pm UTC](https://discuss.elastic.co/t/slow-performance-after-upgrade-from-2-4/128774 "2018-04-19T22:15:44Z") **Posts on this page:** 1 **Showing post:** 2
### 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: [April 27, 2018, 1:30pm UTC](https://discuss.elastic.co/t/slow-performance-after-upgrade-from-2-4/128774/2 "2018-04-27T13:30:17Z")
> [@arthurlm44](#): > > I am wondering if there are any major gotchas that I haven't considered while upgrading from 2.4 to 6. Hard to say really, a lot has changed from 2.x to 6.x. But one major source of slow queries does come to mind. There was a change in how numerics are stored internally, to use a new datastructure. This datastructure is superior for numeric-style queries (ranges, etc). But it is slow to do single point lookups. People get into trouble when they have an identifier which is stored as a numeric value (`12345`), and then query that ID with `term`/`terms` style queries (e.g. "find me this specific ID or IDs). If you have that situation, you should remap your IDs as keywords which are optimized for single term lookups. I wrote some more about it here: [The queries for numeric fields are slower after upgraded the cluster from 2.4.5 to 5.6.3 - #2 by polyfractal](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) Unsure if that's the situation you're running into, but it's a common cause of slower queries after upgrading. --- _[View the full topic](https://discuss.elastic.co/t/slow-performance-after-upgrade-from-2-4/128774)._