anchor.diff:  // TESTRESPONSE[s/\.\.\.//]
   // TESTRESPONSE[s/(?<=[" ])\d+(\.\d+)?/$body.$_path/]
   // TESTRESPONSE[s/"id": "\[P6-vulHtQRWuD4YnubWb7A\]\[test\]\[0\]"/"id": $body.profile.shards.0.id/]
  -<1> The ``"aggregations"` portion has been omitted because it will be covered in the next section
  -
  -As you can see, the output is significantly verbose from before.  All the major portions of the query are
  +<1> The `"aggregations"` portion has been omitted because it will be covered in the next section
  +
  +As you can see, the output is significantly more verbose than before.  All the major portions of the query are
   represented:
   
   1. The first `TermQuery` (user:test) represents the main `term` query
  
positive.code: ==== Performance Notes
  
  Like any profiler, the Profile API introduces a non-negligible overhead to search execution.  The act of instrumenting
  low-level method calls such as `collect`, `advance` and `next_doc` can be fairly expensive, since these methods are called
  in tight loops.  Therefore, profiling should not be enabled in production settings by default, and should not
  be compared against non-profiled query times.  Profiling is just a diagnostic tool.
  
  
negative.code: 
  From the profile structure we can see that the `my_scoped_agg` is internally being run as a `LongTermsAggregator` (because the field it is
  aggregating, `likes`, is a numeric field).  At the same level, we see a `GlobalAggregator` which comes from `my_global_agg`.  That
  aggregation then has a child `LongTermsAggregator` which comes from the second term's aggregation on `likes`.
  
  The `time_in_nanos` field shows the time executed by each aggregation, and is inclusive of all children.  While the overall time is useful,
  the `breakdown` field will give detailed stats about how the time was spent.
  