# Field\_stats\_api deprecated? **URL:** \ **Category:** Elasticsearch\ **Created:** [May 10, 2017, 10:11am UTC](https://discuss.elastic.co/t/field-stats-api-deprecated/85225 "2017-05-10T10:11:02Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![crickes](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/crickes/32/18009_2.png) [@crickes](https://discuss.elastic.co/u/crickes)\ **Post date:** [May 10, 2017, 10:11am UTC](https://discuss.elastic.co/t/field-stats-api-deprecated/85225/1 "2017-05-10T10:11:02Z")
Hi, About a year ago, lots of people from Elastic were singing the praises of the field\_stats\_api, specifically how it can be used to figure out which indices to target a search on. Kibana still uses this mechanism in the background. I came to implement something similar myself yesterday, and found now that it has been deprecated and to use the field\_capabilites API instead, although this doesn't (as far as I can tell), support that one feature of the field\_stats\_api that I wanted. It suggested in the documentation that aggregations can be used instead, but in my scenario, I have too many shards to search against. So I'm curious as to how Kibana is going to change in a future release to cope with the loss of the field\_stats\_api? Here is the problem: For a given index pattern 'daily\_index-\*' we have 30 days of indices. Lets assume that each index has 50 shards, which gives a total of 1500 shards. For a given time range, which could span multiple days, I want to know which indices contain data for that time range. The field\_stats\_api was able to tell you very quickly, which indices contained data spanning the time range in question (current Kibana implementation). An aggregated search against the timestamp will fail (unless I change some limits set in Elasticsearch), as it is hitting more that 1000 shards. The field capabilities API doesn't seem to have the same function. So apart from manually figuring out the index names, how can I get ES to efficiently tell me which indices contain the data I need to search against? I'm sure the clever people writing ES and Kibana, have got a new way to efficiently do this and I'm keen to learn how. Thanks in advance. ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [May 11, 2017, 12:42pm UTC](https://discuss.elastic.co/t/field-stats-api-deprecated/85225/2 "2017-05-11T12:42:27Z")
> [@crickes](#): > > So I'm curious as to how Kibana is going to change in a future release to cope with the loss of the field\_stats\_api? We'll be making changes to cater for it. > [@crickes](#): > > An aggregated search against the timestamp will fail (unless I change some limits set in Elasticsearch), as it is hitting more that 1000 shards. That (soft) limit was removed in 5.4 🙂 > [@crickes](#): > > how can I get ES to efficiently tell me which indices contain the data I need to search against? That I don't know, but I will ask around ---
**Author:** ![crickes](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/crickes/32/18009_2.png) [@crickes](https://discuss.elastic.co/u/crickes)\ **Post date:** [May 11, 2017, 12:46pm UTC](https://discuss.elastic.co/t/field-stats-api-deprecated/85225/3 "2017-05-11T12:46:05Z")
@warkolm Hi, I raised the question as a support ticket, this is the reply I got: > field\_stats is deprecated and the replacement is to use a new endpoint called field\_caps. Although field\_stats was added to solve your problem but in the meantime we improved the handling of range query a lot. > A shard can now very quickly assess if a range query have hits or not and can also cache the result of a range query depending on the min/max values on the shard. For these reasons you should not try to detect which index contain data for the time range but rather let ES do the job. You can just send your query to all indices and the different optimizations for ranges will apply automatically. Kibana is also moving away for field\_stats and will also rely on the range optims. > Bottom line is that ES should do a good job with ranges and you should not have to filter the indices on your side. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [June 8, 2017, 12:52pm UTC](https://discuss.elastic.co/t/field-stats-api-deprecated/85225/4 "2017-06-08T12:52:00Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed. ---
**Author:** ![PhaedrusTheGreek](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/phaedrusthegreek/32/4884_2.png) [@PhaedrusTheGreek](https://discuss.elastic.co/u/PhaedrusTheGreek)\ **Post date:** [October 30, 2017, 12:14pm UTC](https://discuss.elastic.co/t/field-stats-api-deprecated/85225/5 "2017-10-30T12:14:13Z")
Also see "Search Scalability" from [the release post of Elasticsearch 5.6.0](https://www.elastic.co/blog/elasticsearch-5-6-0-released). As of 5.6.0, searches hitting \>= 128 shards are subject to a light pre-filtering phase. Additionally, searches can only run on \ shards concurrently, to help prevent overload.