We discussed about the fact that it might slow down random ranges in FixitFriday. The plan is to first make sure the slow down is contained, and if this is the case merge the change as-is and work on a fix if we later get evidence that there are actual use-cases that this change hurts.

I did some benchmarking on the nyc_taxis dataset and the results are interesting. If I run the below query, then response times go from ~300ms to ~180ms with this PR:

GET nyc_taxis/_search
{
  "profile": true,
  "query": {
    "bool": {
      "must": [
        {
          "match": {
            "payment_type": "3"
          }
        }
      ],
      "filter": [
        {
          "range": {
            "pickup_datetime": {
              "gte": "2015-05-11 16:33:52",
              "lt": "now"
            }
          }
        }
      ]
    }
  }
}

However if I search for 2 (cash) instead of 3 (no charge) as a payment type, then this change actually slows things down from ~1s to ~1.2s. The reason is that it is much more frequent to pay in cash than to have nothing to pay, so in the first case, we only need to check a minority of the documents that match the range and the bottleneck is the execution of the range query, so caching helps. However in the 2nd case we consume most documents from the range and the bottleneck becomes the execution of the implicit disjunction.

Since it's generally better to speed up slow queries, I'm leaning towards not merging this PR. I'll leave it open for some time for discussion if anybody wants to.