title: How does date rounding in elasticsearch work, and how does it affect cache churn?
body: <p>So, I was browsing this slideshow on optimizing elasticsearch queries which seemed pretty useful:</p>
  
  <p><a href="https://speakerdeck.com/elasticsearch/query-optimization-go-more-faster-better" rel="nofollow">https://speakerdeck.com/elasticsearch/query-optimization-go-more-faster-better</a></p>
  
  <p>and it mentions avoiding cache churn by using something similar to:</p>
  
  <pre><code>curl -XGET 'localhost:9200/_all/_search?search_type=count' -d '
  {
      "query" : {
          "filtered" : {
                "filter" : {
                  "bool" : {
                      "must" : [
                          {"range" : {
                              "@timestamp" : {
                                  "gte" : "now/d"
                              }
                          }},
                          {"range" : {
                              "@timestamp" : {
                                  "gte" : "now-1h"
                              },
                              "_cache" : false
                          }}
                      ]
                  }
                }
  
          }
      }
  }'
  </code></pre>
  
  <p>So, the question is: how does date rounding work?</p>
  
  <p>Specifically, what does now/d actually refer to?  Does that simply equate to "today"?  But, does that mean "today according to my local computer running the query" or "today according to the timezone of the computer running the elasticsearch cluster"?  I guess it's hard to differentiate that since most people run on localhost, or their computer running the elasticsearch cluster is most likely set to the same time zone...  But I guess that's a minor question.</p>
  
  <p>I guess, I see this filtered query to mean: "search all indices - it must be from today, and it must be from within the past hour."  I can see where - "it must be from today" is a filter that should be cached since it can be reused.  The elasticsearch github issues mentions this at <a href="https://github.com/elasticsearch/elasticsearch/issues/4947" rel="nofollow">https://github.com/elasticsearch/elasticsearch/issues/4947</a></p>
  
  <p>and I see how it can help with avoiding cache churn, but I was actually thinking it is more useful if it was less than or equal to rather than greater than or equal to such as:</p>
  
  <pre><code>"lte" : "now/d"
  </code></pre>
  
  <p>which is to say "search all indices - it must be from today or earlier, and it must be from within the past hour." In my opinion, this makes sense because it makes "today or earlier" a constant end point and allows you to search backwards from that now-stationary time point.  This means that you can use this type of filter combination to avoid cache churn and search in the past rather than being limited to searching things from "today".  However, I am not sure if the lte version still helps to avoid cache churn.  Can anyone clarify the issue?</p>