anchor.diff:  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.
  +<<terms-agg-doc-count-error,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
  
positive.code:       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
  
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>>
  
  