anchor.diff:  }
   --------------------------------------------------
   
  -On top of this also a mapping type can be associated with the this query. This allows to control how certain queries
  +On top of this also a mapping type can be associated with this query. This allows to control how certain queries
   like range queries, shape filters and other query & filters that rely on mapping settings get constructed. This is
   important since the percolate queries are indexed into the `.percolator` type, and the queries / filters that rely on
   mapping settings would yield unexpected behaviour. Note by default field names do get resolved in a smart manner,
  
positive.code: === Dedicated percolator index
  
  Percolate queries can be added to any index. Instead of adding percolate queries to the index the data resides in,
  these queries can also be added to an dedicated index. The advantage of this is that this dedicated percolator index
  can have its own index settings (For example the number of primary and replicas shards). If you choose to have a dedicated
  percolate index, you need to make sure that the mappings from the normal index are also available on the percolate index.
  Otherwise percolate queries can be parsed incorrectly.
  
negative.code: At percolate time the document specified in the request gets parsed into a Lucene document and is stored in a in-memory
  Lucene index. This in-memory index can just hold this one document and it is optimized for that. Then all the queries
  that are registered to the index that the percolate request is targeted for are going to be executed on this single document
  in-memory index. This happens on each shard the percolate request needs to execute.
  
  By using `routing`, `filter` or `query` features the amount of queries that need to be executed can be reduced and thus
  the time the percolate api needs to run can be decreased.
  