<p dir="auto"><strong>Describe the feature</strong>:<br>
Add date math support to the field stats API. The ability to do something like this could be useful:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="GET metricbeat-*/_field_stats?level=indices
{
  &quot;fields&quot;: [&quot;@timestamp&quot;],
  &quot;index_constraints&quot;: {
    &quot;@timestamp&quot;: {
      &quot;max_value&quot;: {
        &quot;lt&quot;:&quot;now-30d&quot;
      }
    }
  }
}"><pre class="notranslate"><code class="notranslate">GET metricbeat-*/_field_stats?level=indices
{
  "fields": ["@timestamp"],
  "index_constraints": {
    "@timestamp": {
      "max_value": {
        "lt":"now-30d"
      }
    }
  }
}
</code></pre></div>
<p dir="auto">It could help with managing time series indices. Other uses?</p>
<p dir="auto">Currently, the <code class="notranslate">_optimize</code> API exists to optimize an entire index by merging segments in the background. In general, it's key to merge all segments to 1 (<code class="notranslate">max_num_segments=1</code>). However, if you have a very high workload, then it can be a very slow and expensive operation. Worse, optimizing an index that has replicas requires that both the primary and replica(s) be optimized separately.</p>
<p dir="auto">It would be great if we could provide an improved optimize API that allows further control:</p>
<ul dir="auto">
<li>Optimize specific shards of an index
<ul dir="auto">
<li>This would be particularly helpful with routing scenarios where shards could be tuned as-needed without impacting the rest of the shards (note: for time based indices, it's still optimal to optimize all of them, but it may be easier to wait for the remaining shards)</li>
<li>It also has the added benefit that you can better predict its impact, both in terms of file capacity <em>and</em> processing. Since you may have multiple shards per node, it also avoids running them in parallel.</li>
</ul>
</li>
<li>Choose to optimize a specific shard (not only the shard, but which node if replica shards exist)</li>
<li>Offer the ability to optimize a single shard, then copy the optimized shard rather than duplicating the effort on its primary/replica peer.
<ul dir="auto">
<li>This would allow people to choose to spend a little bit of short lived memory and network bandwidth rather than the current overhead associated (processing, longer lived memory, and more IO).</li>
</ul>
</li>
</ul>