Don't use the `and` filter - use the `bool` filter instead.  They have
different execution modes and the `bool` filter works best with bitset
filters (but also knows how to handle non-bitset filters like geo etc).

Just remove the `and`, `or` and `not` filters from your DSL vocabulary.

Also, not sure why you are ANDing with a match_all filter - that doesn't
make much sense.

Depending on which version of ES you're using, you may be encountering a
bug in the filtered query which ended up always running the query first,
instead of the filter. This was fixed in v1.2.0
https://github.com/elasticsearch/elasticsearch/issues/6247 .  If you are on
an earlier version you can force filter-first execution manually by
specifying a "strategy" of "random_access_100".  See
http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-filtered-query.html#_filter_strategy

In summary, (and taking your less granular datetime clause into account)
your query would be better written as:

    GET /_search
    {
      "query": {
        "filtered": {
          "strategy": "random_access_100",  #### pre 1.2 only
          "filter": {
            "bool": {
              "must": [
                {
                  "terms": {
                    "source_id": [ "s1", "s2", "s3" ]
                  }
                },
                {
                  "range": {
                    "published": {
                      "gte": "now-1d/d"  #### coarse grained, cached
                    }
                  }
                },
                {
                  "range": {
                    "published": {
                      "gte": "now-30m" #### fine grained, not cached, could
use fielddata too
                    },
                    "_cache": false
                  }
                }
              ]
            }
          }
        }
      }
    }





On 30 July 2014 10:55, David Pilato <[email protected]> wrote:

> May be a stupid question: why did you put that filter inside a query and
> not within the same filter you have at the end?
>
>
> For my test case it's the same every time. In the "real" query it will
>> change every time, but I planned to not cache this filter and have a less
>> granular date filter in the bool filter that would be cached. However while
>> debugging I noticed slowness with the date range filters even while testing
>> with the same value repeatedly.
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "elasticsearch" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elasticsearch/af76ca41-9045-4a4f-b82c-b9c86d964ace%40googlegroups.com
> <https://groups.google.com/d/msgid/elasticsearch/af76ca41-9045-4a4f-b82c-b9c86d964ace%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elasticsearch/CAPt3XKRQ6tyciPDVKVnCz0nzgq9B89y6irh3N1Ergf-oCW2Z%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to