anchor.diff:  
   ===== Filtering Values with partitions
   
  -Sometimes there are too many unique terms to process in a single request/response pair so 
  +Sometimes there are too many unique terms to process in a single request/response pair so
   it can be useful to break the analysis up into multiple requests.
   This can be achieved by grouping the field's values into a number of partitions at query-time and processing
   only one partition in each request.
  
positive.code: 
  There are two error values which can be shown on the terms aggregation. The first gives a value for the aggregation as
  a whole which represents the maximum potential document count for a term which did not make it into the final list of
  terms. This is calculated as the sum of the document count from the last term returned from each shard. For the example
  given above the value would be 46 (2 + 15 + 29). This means that in the worst case scenario a term which was not returned
  could have the 4th highest document count.
  
  [source,console-result]
  --------------------------------------------------
  {
      ...
      "aggregations" : {
          "products" : {
              "doc_count_error_upper_bound" : 46,
              "sum_other_doc_count" : 79,
              "buckets" : [
                  {
                      "key" : "Product A",
                      "doc_count" : 100
                  },
                  {
                      "key" : "Product Z",
                      "doc_count" : 52
                  }
                  ...
              ]
          }
      }
  }
  --------------------------------------------------
  // TESTRESPONSE[s/\.\.\.//]
  // TESTRESPONSE[s/: (\-)?[0-9]+/: $body.$_path/]
  
  ==== Per bucket document count error
  
  
negative.code: This request is finding the last logged access date for a subset of customer accounts because we
  might want to expire some customer accounts who haven't been seen for a long while.
  The `num_partitions` setting has requested that the unique account_ids are organized evenly into twenty
  partitions (0 to 19). and the `partition` setting in this request filters to only consider account_ids falling
  into partition 0. Subsequent requests should ask for partitions 1 then 2 etc to complete the expired-account analysis.
  
  Note that the `size` setting for the number of results returned needs to be tuned with the `num_partitions`.
  For this particular account-expiration example the process for balancing values for `size` and `num_partitions` would be as follows:
  
  1. Use the `cardinality` aggregation to estimate the total number of unique account_id values
  