# Cardinality agg off by one even after precision increase

**URL:** <https://discuss.elastic.co/t/cardinality-agg-off-by-one-even-after-precision-increase/283096>\
**Category:** Elasticsearch\
**Created:** [September 1, 2021, 7:33pm UTC](https://discuss.elastic.co/t/cardinality-agg-off-by-one-even-after-precision-increase/283096 "2021-09-01T19:33:47Z")\
**Posts on this page:** 1\
**Showing post:** 2

<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:** [September 2, 2021, 7:50am UTC](https://discuss.elastic.co/t/cardinality-agg-off-by-one-even-after-precision-increase/283096/2 "2021-09-02T07:50:06Z")

</div>

> I've set the precision threshold to 6000 or higher, without any change.

The precision threshold doesn't mark the boundary between accurate and inaccurate - just use of counting technique 1 versus counting technique 2. Counting technique 1 is less susceptible to inaccuracies but is still not guaranteed to be fully accurate. That said, it is based on collecting hashes of values which can occasionally collide so I'd have expected an under-count rather than an over-count. One possible explanation is that a value may be held in different field types across indices, in which case string `1234` != integer `1234` when merging results from the different indices.

---

_[View the full topic](https://discuss.elastic.co/t/cardinality-agg-off-by-one-even-after-precision-increase/283096)._
