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:
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: