: I don't believe however that the two queries (the one with the post filter
: and the one without one) are equivalent.
:
: Suppose out of the whole document set:
: XXX returns documents 1,2,3.
: AAA returns documents 6,7,8.
: {!frange}customfunction returns documents 7,8.
:
: Running this query:
: XXX OR AAA AND {!frange ...}
: Matched documents are:
: (1,2,3) OR (6,7,8) AND (7,8) = (1,2,3) OR (7,8) = 1,2,3,7,8
Did you actually test out that specific example, because those results
don't make sense to me given how the parser deals with multiple AND and OR
keywords in a single BooleanQuery (which is why i hate AND and OR and
advise anyone who will listen to never use them)...
http://searchhub.org//2011/12/28/why-not-and-or-and-not/
$ curl -sS
'http://localhost:8983/solr/select?q=xxx%20OR%20AaA%20AND%20zZz&debug=query&wt=json&indent=true'
| grep xxx
"q":"xxx OR AaA AND zZz",
"rawquerystring":"xxx OR AaA AND zZz",
"querystring":"xxx OR AaA AND zZz",
"parsedquery":"text:xxx +text:aaa +text:zzz",
"parsedquery_toString":"text:xxx +text:aaa +text:zzz",
Based on your walk through of the logic you'd like to have,
it seems like the query you ment to write is something like this...
XXX (+AAA +{!frange ...})
...aka...
XXX OR (AAA AND {!frange ...})
...in which case i'm afraid i don't have many good suggestions for you on
how to minimize the number of times the function is called to eliminate
any doc that already matches XXX (or to force it to check AAA first)
Looking at one of your specific examples...
: Document id 1:
: Does it match XXX? Yes. Document matches query. Skip the second clause (AAA
: AND {!frange ...}) and evaluate next doc.
...this type of skipping fundementally can't happen with a BooleanQuery
because of the way scoring works in lucene -- even if it matches the XXX
clause, the other clauses will still be consulted to determine what the
total score will be -- all SHOULD and MUST clauses that match contribute
to the final score.
: I hope I'm not rambling. :-)
: Does it make sense?
You're not rambling -- there's ust no general way to force the kind
of "check this last" optimization you're hoping for in all cases, and
even if there was, it wouldn't help you as much as you might think because
of the scoring.
-Hoss
http://www.lucidworks.com/
