|
Query vs Filter-QueryCriteria 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. |
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:
