# Slow terms aggregation speed on ~130M documents **URL:** \ **Category:** Elasticsearch\ **Created:** [February 7, 2018, 6:32am UTC](https://discuss.elastic.co/t/slow-terms-aggregation-speed-on-130m-documents/118759 "2018-02-07T06:32:11Z")\ **Posts on this page:** 1\ **Showing post:** 30
**Author:** ![jdgenio](https://avatars.discourse-cdn.com/v4/letter/j/b9bd4f/32.png) [@jdgenio](https://discuss.elastic.co/u/jdgenio)\ **Post date:** [February 8, 2018, 9:57am UTC](https://discuss.elastic.co/t/slow-terms-aggregation-speed-on-130m-documents/118759/30 "2018-02-08T09:57:29Z")
We close the ES servers after office hours so I can't make queries right now to verify but earlier, the normal searches were taking around a little higher than 4 seconds while the one with the map execution hint took around 3.5 seconds, but some of the lower result queries were taking 2 or less. I'd have to perform a proper benchmark tomorrow and get back to you. > [@Mark\_Harwood](#): > > Global ordinals execution mode aggregates information using numbers that each represent unique strings in the index. This means the memory overhead for labelling buckets is smaller than the length of the strings they replace but there's an overhead in the conversion. > > map execution tags the buckets being aggregated directly with the indexed value which could be long in some cases (imagine URL strings). If your query matches a lot of docs that's a lot of strings to hold in memory before they are pruned to your top N selection. That makes a lot of sense, thank you for the explanation. If I understand correctly, @dadoonet's recommendation would then negate the global ordinal conversion overhead since it would eagerly build the global 'hashtable'? --- _[View the full topic](https://discuss.elastic.co/t/slow-terms-aggregation-speed-on-130m-documents/118759)._