# Terms aggregation + Cardinality Aggregation performance

**URL:** <https://discuss.elastic.co/t/terms-aggregation-cardinality-aggregation-performance/87365>\
**Category:** Elasticsearch\
**Created:** [May 28, 2017, 1:53pm UTC](https://discuss.elastic.co/t/terms-aggregation-cardinality-aggregation-performance/87365 "2017-05-28T13:53:04Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![jonyadamit](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jonyadamit/32/18575_2.png) [@jonyadamit](https://discuss.elastic.co/u/jonyadamit)\
**Post date:** [May 28, 2017, 1:53pm UTC](https://discuss.elastic.co/t/terms-aggregation-cardinality-aggregation-performance/87365/1 "2017-05-28T13:53:04Z")

</div>

My terms aggregation (on a high cardinality field) with an inner cardinality aggregation takes about 23 seconds to complete (one node, one shard, 300,000 documents, keyword fields).  
The equivalent SQL query using SQL server takes a few seconds at most.

**Is it reasonable of me to make that comparison? Maybe SQL Server is just more suited for this kind of queries?**

I posted a related question with much more detail on Stack Overflow ([https://stackoverflow.com/q/44225038/1545350](https://stackoverflow.com/q/44225038/1545350)) if anyone cares to assist there as well.

Thanks, Jonathan.

---

<div class="post-metadata">

**Author:** ![Mark\_Harwood](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mark_harwood/32/10538_2.png) [@Mark\_Harwood](https://discuss.elastic.co/u/Mark_Harwood)\
**Post date:** [May 28, 2017, 9:30pm UTC](https://discuss.elastic.co/t/terms-aggregation-cardinality-aggregation-performance/87365/2 "2017-05-28T21:30:56Z")

</div>

Try reduce the `precision_threshold` [1] setting to reduce the memory used to calculate these values for each of your many order\_id buckets. The default value is 3,000 and I imagine the average number of items per order falls way below this value.

[1] [https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-metrics-cardinality-aggregation.html#\_precision\_control](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-metrics-cardinality-aggregation.html#_precision_control)

---

<div class="post-metadata">

**Author:** ![jonyadamit](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jonyadamit/32/18575_2.png) [@jonyadamit](https://discuss.elastic.co/u/jonyadamit)\
**Post date:** [May 29, 2017, 9:25am UTC](https://discuss.elastic.co/t/terms-aggregation-cardinality-aggregation-performance/87365/3 "2017-05-29T09:25:31Z")

</div>

Thanks! Didn't know it had this kind of effect on memory consumption!  
This indeed lowers memory consumption for me below the circuit breaker.  
Performance wasn't affected that much by this change, but it does help.

Side note - my comparison with SQL Server was faulted because of caching.

---

<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:** [June 26, 2017, 9:26am UTC](https://discuss.elastic.co/t/terms-aggregation-cardinality-aggregation-performance/87365/4 "2017-06-26T09:26:02Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.