Make delicious recipes!

Query vs Filter-Query



Criteria specified in Filter-Query(FQ) do not affect the ranking. Thus a query can be made faster by converting some of its criteria into a filter-query parameter. On the other hand, FQ criteria count towards the filter-cache and can increase the size of filter-cache. So one should try to balance these two factors to get the best of both the worlds.

Note that when Q and FQ are both present, it is efficient to apply the FQ filters first. Each FQ parameter would yield a bit-vector of document-IDs (and this might come from the filter-cache, thus being very efficient). All bit-vectors are then intersected to get the document set on which Q can operate. This is better than running Q first on all the documents and then applying FQ to the result set.

Filter-Queries can have a cost parameter.
Higher the cost, later the filter is applied.
For example:
fq={!cost=1}price=500.0&
fq={!cost=2}name="iphone"&
fq={!cost=100 cache=false}div(log(age),sqrt(geodist()))

The numerical filter is the fastest to apply. So its given a weight of 1.
Next is a string comparison filter and that is given a weight of 2 (so that its applied after the price filter).
The last filter with a weight of 100 is very expensive since it does a bunch of computations, so its given a weight of 100 to make it applied at the end.

Filters with cost > 100 are considered post-filters. Such filters are applied after all filters and even after the query Q has also been applied. These are the filters which have been found to be extremely expensive and so need a very minimal set of documents possible.













Like us on Facebook to remain in touch
with the latest in technology and tutorials!


Got a thought to share or found a
bug in the code?
We'd love to hear from you:

Name:
Email: (Your email is not shared with anybody)
Comment:

Facebook comments:

Site Owner: Sachin Goyal