Skip to content

Conversation

@jpountz
Copy link
Contributor

@jpountz jpountz commented Jul 1, 2016

Today the default precision for the cardinality aggregation depends on how many
parent bucket aggregations it had. The reasoning was that the more parent bucket
aggregations, the more buckets the cardinality had to be computed on. And this
number could be huge depending on what the parent aggregations actually are.

However now that we run terms aggregations in breadth-first mode by default when
there are sub aggregations, it is less likely that we have to run the cardinality
aggregation on kagilions of buckets. So we could use a static default, which will
be less confusing to users.

@jpountz jpountz force-pushed the enhancement/cardinality_static_default_precision branch from 2f364f9 to cab49e5 Compare July 1, 2016 15:22
@jimczi
Copy link
Contributor

jimczi commented Jul 5, 2016

LGTM

@jpountz jpountz force-pushed the enhancement/cardinality_static_default_precision branch from cab49e5 to ff155d3 Compare July 18, 2016 09:28
…ic#19215

Today the default precision for the cardinality aggregation depends on how many
parent bucket aggregations it had. The reasoning was that the more parent bucket
aggregations, the more buckets the cardinality had to be computed on. And this
number could be huge depending on what the parent aggregations actually are.

However now that we run terms aggregations in breadth-first mode by default when
there are sub aggregations, it is less likely that we have to run the cardinality
aggregation on kagilions of buckets. So we could use a static default, which will
be less confusing to users.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants