: Let's take this query sample:
: XXX OR AAA AND {!frange ...}
:
: For my use case:
: AAA returns a subset of 100k documents.
: frange returns 5k documents, all part of these 100k documents.
:
: Therefore, frange skips the most documents. From what you are saying,
: frange is going to be applied on all documents (since it skips the most
: documents) and AAA is going to be applied on the subset. This is kind of
: what I've originally noticed. My goal is to have this in reverse order,
That's not exactly it ... there's no way for the query to know in advance
how many documents it matches -- what BooleanQuery asks each clause is
"looking at the index, tell me the (internal) lucene docid of the first do
you match. it then looks at the lowest matching docid of each clause, and
the "Occur" property of the clause (MUST, MUST_NOT, SHOULD) to be able to
tell if/when it can say things like "clause AAA is mandatory but the
lowest id it matches is doc# 8675 -- so it doesn't mater that clause XXX's
lowest match is doc# 10 or that clause {!frange}'s lowest matche is doc#
100"
it can then ask XXX and {!frange} to both "skip" ahead, and find lowest
docid they each match that is no less then 8675, etc...
from the perspective of {!frange} in particular, this means that on the
first call it will evaluate itself against docid #0, #1, #2, etc... untill
it finds a match. and on the secod call it will evaluate itself against
docid #8675, 8676, etc... until it finds a match...
: since frange is much more expensive than AAA.
: I was hoping to do so by specifying the cost, saying that "Hey, frange has
There is no support for specifying cost on individual clauses instead of a
BooleanQuery.
But i really want to re-iterate, that even with the example you posted
above you *still* don't need to nest your {!frange} instead of a boolean
query -- what you have is this:
XXX OR AAA AND {!frange ...}
in which the {!frange ...} clause is completely mandatory -- so my
previous point #2 still applies...
: > 2) based on the example you give, what you're trying to do here doesn't
: > really depend on using "SHOULD" (ie: OR) type logic against the frange:
: > the only disjunction you have is in a sub-query of a top level
: > conjunction (e: all required) ... the frange itself is still mandatory.
: >
: > so you could still use it as a non-cached postfilter just like in your
: > previous example:
q=XXX OR AAA & fq={!frange cost=150 cache=false ...}
-Hoss
http://www.lucidworks.com/
