# FieldStats support **URL:** \ **Category:** Elasticsearch\ **Created:** [November 10, 2017, 7:23am UTC](https://discuss.elastic.co/t/fieldstats-support/107144 "2017-11-10T07:23:43Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![gphadke](https://avatars.discourse-cdn.com/v4/letter/g/ecc23a/32.png) [@gphadke](https://discuss.elastic.co/u/gphadke)\ **Post date:** [November 10, 2017, 7:23am UTC](https://discuss.elastic.co/t/fieldstats-support/107144/1 "2017-11-10T07:23:43Z")
Hello FieldStats is removed in ES 6.0. Wanted to know if the functionality is provided by any other API or combination of APIs. We have been using it to filter numbers of indices to search which store time series data. We have been using the FieldStatsRequestBuilder with constraints to find the indices. We have also been using FieldStats to get min and max values stored in a field. Is there a way to get these in absence of FieldStats? regards Gopal ---
**Author:** ![spinscale](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/spinscale/32/25011_2.png) [@spinscale](https://discuss.elastic.co/u/spinscale)\ **Post date:** [November 10, 2017, 9:38am UTC](https://discuss.elastic.co/t/fieldstats-support/107144/2 "2017-11-10T09:38:44Z")
Hey, I assume you filtered down, because you did not want to spread your search across a wide number of shards? Elasticsearch added safeguards against this (running several rounds), so this should not be a concern. See [https://github.com/elastic/elasticsearch/pull/25658](https://github.com/elastic/elasticsearch/pull/25658) could min/max values just become an aggregation in your case? --Alex ---
**Author:** ![gphadke](https://avatars.discourse-cdn.com/v4/letter/g/ecc23a/32.png) [@gphadke](https://discuss.elastic.co/u/gphadke)\ **Post date:** [November 14, 2017, 6:40pm UTC](https://discuss.elastic.co/t/fieldstats-support/107144/3 "2017-11-14T18:40:02Z")
Thanks. The min/max aggregation should work for us. Just wondering how field\_stats vs min/max aggregation compare on performance? For the safeguard change : "This change adds a pre-filter phase for searches that can, if the number of shards are higher than a the pre\_filter\_shard\_size threshold (defaults to 128 shards), fan out to the shards and check if the query can potentially match any documents at all." It is not entirely clear to me from the PR how this works, if you can give more details about how pre\_filter uses the query and which fields from the query it may use to filter out, it will help to understand how this works. Thanks Gopal ---
**Author:** ![theuntergeek](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/theuntergeek/32/44961_2.png) [@theuntergeek](https://discuss.elastic.co/u/theuntergeek)\ **Post date:** [November 14, 2017, 6:57pm UTC](https://discuss.elastic.co/t/fieldstats-support/107144/4 "2017-11-14T18:57:57Z")
It should actually be more performant, as doing min/max only are fewer calculations than field\_stats was doing. ---
**Author:** ![spinscale](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/spinscale/32/25011_2.png) [@spinscale](https://discuss.elastic.co/u/spinscale)\ **Post date:** [November 15, 2017, 9:40am UTC](https://discuss.elastic.co/t/fieldstats-support/107144/5 "2017-11-15T09:40:33Z")
The magic happens in [SearchService.canMatch()](https://github.com/elastic/elasticsearch/blob/master/core/src/main/java/org/elasticsearch/search/SearchService.java#L941-L956) ES is able to rewrite queries internally, some of those queries for example get rewritten to a MatchNoneQuery and thus can be fully ignored. ---
**Author:** ![trevan](https://avatars.discourse-cdn.com/v4/letter/t/7feea3/32.png) [@trevan](https://discuss.elastic.co/u/trevan)\ **Post date:** [November 17, 2017, 6:29pm UTC](https://discuss.elastic.co/t/fieldstats-support/107144/6 "2017-11-17T18:29:28Z")
I haven't see min/max aggregation as being more performant than \_field\_stats in 5.6. In my cluster, if I do a \_field\_stats for one field, I can get it back for all indices in usually less than a second. If I do a min/max aggregation for the same field with an \_index aggregation (so I can get the same data as \_field\_stats), it takes \>10 seconds. ---
**Author:** ![gphadke](https://avatars.discourse-cdn.com/v4/letter/g/ecc23a/32.png) [@gphadke](https://discuss.elastic.co/u/gphadke)\ **Post date:** [December 5, 2017, 8:27am UTC](https://discuss.elastic.co/t/fieldstats-support/107144/7 "2017-12-05T08:27:38Z")
@spinscale @theuntergeek Can you please comment on the performance comment made here by @trevan . Why the aggregations may be slower? ---
**Author:** ![theuntergeek](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/theuntergeek/32/44961_2.png) [@theuntergeek](https://discuss.elastic.co/u/theuntergeek)\ **Post date:** [December 5, 2017, 1:03pm UTC](https://discuss.elastic.co/t/fieldstats-support/107144/8 "2017-12-05T13:03:39Z")
@gphadke, @trevan that can only happen in `field_stats` if the results have been cached in memory. That's why it can return that quickly. If the results are not cached—for example, you just restarted each node in the cluster, so nothing is in memory—then the `field_stats`query will take more time, too, as it has to go to the indices for the results (and then cache them). Aggregations using `doc_values` will also cache, but in the filesystem cache, rather than the JVM. Performance will depend on the operating system's abilities at that point, and whether those values stay in the cache. ---
**Author:** ![trevan](https://avatars.discourse-cdn.com/v4/letter/t/7feea3/32.png) [@trevan](https://discuss.elastic.co/u/trevan)\ **Post date:** [December 5, 2017, 3:45pm UTC](https://discuss.elastic.co/t/fieldstats-support/107144/9 "2017-12-05T15:45:21Z")
@theuntergeek, would \_cache/clear have the same affect on field\_stats? Because I've done that and it is still 1-2 seconds at most. The only time I've ever seen field\_stats and an equivalent aggregation have the same speed is when the equivalent aggregation is in the query cache which never seems to happen under real-world conditions since the timespan is always changing. Otherwise, field\_stats, with and without caching, has always been extremely faster than an aggregation. ---
**Author:** ![theuntergeek](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/theuntergeek/32/44961_2.png) [@theuntergeek](https://discuss.elastic.co/u/theuntergeek)\ **Post date:** [December 5, 2017, 4:07pm UTC](https://discuss.elastic.co/t/fieldstats-support/107144/10 "2017-12-05T16:07:25Z")
That API only clears filter cache, if I recall correctly. `field_stats` is safe to use within constraints, but can balloon memory out of control. Use it with caution. ---
**Author:** ![spinscale](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/spinscale/32/25011_2.png) [@spinscale](https://discuss.elastic.co/u/spinscale)\ **Post date:** [December 6, 2017, 8:51am UTC](https://discuss.elastic.co/t/fieldstats-support/107144/11 "2017-12-06T08:51:46Z")
You could however use the [shard request cache](https://www.elastic.co/guide/en/elasticsearch/reference/6.0/shard-request-cache.html) to cache the aggregation results. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [January 3, 2018, 8:52am UTC](https://discuss.elastic.co/t/fieldstats-support/107144/12 "2018-01-03T08:52:18Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.