Hmmm, are you talking about SOLR--2429? Some context would help here...
But if you are, that capability was added to deal with situations where
calculating the fq for the entire corpus *then* applying it to the query
results was too expensive. So when you specify one of these "high cost"
filters, Solr calculates the set of docs that staisfies the initial query,
complete with relevance scores. Then all the lower-cost fqs are applied
which will be cached (assuming they aren't identified as "high cost", the
the "high cost" fq is applied to the results set. That is, each document
that has made it through the initial query selection and all of the
lower-cost fqs has the high-cost fq value (i.e. inclusion/exclusion)
calculated and the doc is removed from the result set if it should be. I
haven't dived into the code to really understand the bit about "calculated
in parallel"...
Best
Erick
On Dec 9, 2011 4:53 PM, "Andrew Lundgren" wrote:
> I know that fq's are used to improve performance by reducing the data set
> that you score.
>
> I have read the documentation that says that non-cached fq's are created
> in parallel to your query, but would like to know more about how that is
> done.
>
> Does it do a match on all the FQ's, then AND the resulting doc sets and
> then once that is done score the query based on the resulting subset of
> documents?
>
>
> --
> Andrew Lundgren
> lundg...@familysearch.org
>
>
> NOTICE: This email message is for the sole use of the intended
> recipient(s) and may contain confidential and privileged information. Any
> unauthorized review, use, disclosure or distribution is prohibited. If you
> are not the intended recipient, please contact the sender by reply email
> and destroy all copies of the original message.
>
>
>
