anchor.diff:  // TESTRESPONSE[s/}$/},\n"children": $body.$_path}],\n"rewrite_time": $body.$_path, "collector": $body.$_path}], "aggregations": []}]}}/]
   // TESTRESPONSE[s/(?<=[" ])\d+(\.\d+)?/$body.$_path/]
   
  -Timings are listed in wall-clock nanoseconds and are not normalized at all.  All caveats about the overall
  -`time_in_nanos` apply here.  The intention of the breakdown is to give you a feel for A) what machinery in Lucene is
  -actually eating time, and B) the magnitude of differences in times between the various components.  Like the overall time,
  -the breakdown is inclusive of all children times.
  +Timings are listed in wall-clock nanoseconds and are not normalized at all. All 
  +caveats about the overall `time_in_nanos` apply here.  The intention of the 
  +breakdown is to give you a feel for A) what machinery in Lucene is actually 
  +eating time, and B) the magnitude of differences in times between the various 
  +components. Like the overall time, the breakdown is inclusive of all children 
  +times.
   
   The meaning of the stats are as follows:
   
  
positive.code: // TESTRESPONSE[s/"query": \[...\]/"query": $body.$_path/]
  // TESTRESPONSE[s/"collector": \[...\]/"collector": $body.$_path/]
  // TESTRESPONSE[s/"aggregations": \[...\]/"aggregations": []/]
  <1> A profile is returned for each shard that participated in the response, and is identified
  by a unique ID
  <2> Each profile contains a section which holds details about the query execution
  <3> Each profile has a single time representing the cumulative rewrite time
  <4> Each profile also contains a section about the Lucene Collectors which run the search
  <5> Each profile contains a section which holds the details about the aggregation execution
  
  Because a search request may be executed against one or more shards in an index, and a search may cover
  one or more indices, the top level element in the profile response is an array of `shard` objects.
  Each shard object lists its `id` which uniquely identifies the shard.  The ID's format is
  `[nodeID][indexName][shardID]`.
  
  The profile itself may consist of one or more "searches", where a search is a query executed against the underlying
  Lucene index.  Most search requests submitted by the user will only execute a single `search` against the Lucene index.
  But occasionally multiple searches will be executed, such as including a global aggregation (which needs to execute
  a secondary "match_all" query for the global context).
  
  Inside each `search` object there will be two arrays of profiled information:
  a `query` array and a `collector` array.  Alongside the `search` object is an `aggregations` object that contains the profile information for the aggregations. In the future, more sections may be added, such as `suggest`, `highlight`, etc.
  
  There will also be a `rewrite` metric showing the total time spent rewriting the query (in nanoseconds).
  
  NOTE: As with other statistics apis, the Profile API supports human readable outputs. This can be turned on by adding
  `?human=true` to the query string. In this case, the output contains the additional `time` field containing rounded,
  
negative.code: - A global aggregation
  - A post_filter
  
  
  The API returns the following result:
  
  [source,console-result]
  --------------------------------------------------
  