anchor.diff:        allows to paginate over all possible terms rather than setting a size greater than the cardinality of the field in the
         `terms` aggregation. The `terms` aggregation is meant to return the `top` terms and does not allow pagination.
   
  -[[search-aggregations-bucket-terms-aggregation-approximate-counts]]
  -==== Document counts are approximate
  -
  -Document counts (and the results of any sub aggregations) in the terms
  -aggregation are not always accurate. Each shard provides its own view of what
  -the ordered list of terms should be. These views are combined to give a final
  -view.
  -
   ==== Shard Size
   
   The higher the requested `size` is, the more accurate the results will be, but also, the more expensive it will be to
  
positive.code: their `doc_count` descending. It is possible to change this behaviour as documented below:
  
  WARNING: Sorting by ascending `_count` or by sub aggregation is discouraged as it increases the
  <<search-aggregations-bucket-terms-aggregation-approximate-counts,error>> on document counts.
  It is fine when a single shard is queried, or when the field that is being aggregated was used
  as a routing key at index time: in these cases results will be accurate since shards have disjoint
  values. However otherwise, errors are unbounded. One particular case that could still be useful
  
negative.code: --------------------------------------------------
  // TESTRESPONSE[s/\.\.\.//]
  
  <1> an upper bound of the error on the document counts for each term, see <<terms-agg-doc-count-error,below>>
  <2> when there are lots of unique terms, Elasticsearch only returns the top terms; this number is the sum of the document counts for all buckets that are not part of the response
  <3> the list of the top buckets, the meaning of `top` being defined by the <<search-aggregations-bucket-terms-aggregation-order,order>>
  
  