I have a filtered query, and within the filter I want to accomplish
something like this
(X AND Y AND ...) AND (A OR B OR ...) AND (C OR D OR ...)
where X, Y, A, B, C, D are all filter expressions and each set of
expressions within the params can be arbitrary in length
Originally, before the requirement for that extra C or D term at the end, I
was constructing a query that looked like this:
"should": ["A" , "B", ...],
"must": ["X", "Y", ...]
Now, to take into account the third set of filters I'm thinking I need to
move to something like this:
( X, Y, A, B, C, D are all separate filter expressions themselves)
I read this helpful post (section regarding bool vs and/or/not):
I'm not using any geo or similar filters in the underlying filter
expressions, just term filters and term filters with lookup mechanism, so
should I be trying to avoid introducing the OR filter?
Is there a better way to construct the set of filters I'm constructing
In the thread, Clint writes
"and/or/not filters don't demand bitsets. They work doc-by-doc, so
they're a good fit for geo filters. They also short-circuit. If a doc
has already been excluded by an earlier filter, it won't run the later
But the fact that they don't "demand" bitsets, does that mean they don't
take advantage of bitsets if the underlying filters DO provide them? So is
there an inherent (performance) disadvantage to using them?
Thanks for your help!
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@example.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/140494bd-d10c-4d74-a068-014163089029%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.