lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley" <>
Subject Re: Leveraging filter chache in queries
Date Fri, 12 May 2006 14:15:07 GMT
On 5/12/06, Fabio Confalonieri <> wrote:
> I tried a query like "+field:value^0" which returns a great number of Hits
> (on a total test of 100.000 documents), but I see only the query cache
> growing and the filter cache always empty. Is this normal ? I've tried to
> check all the cache configuration but I don't understand if filters are
> auto-generated from normal queries.

There is currently no syntax in the standard request handler that
understands filters.

Converting certain "heavy" term queries to filters when they have a
zero boost was something Doug pointed me at and I borrowed directly
from Nutch very early on, before Solr had it's own caching.

The optimization code is still sort-of in Solr, but
 - it's not called by default anymore... people needing faceted
browsing currently need their own plugin anyway, and they can then
specify filters directly.
 - it's caching is not integrated into Solr's caching

Filters *can* be generated and used to satisfy whole queries when the
following optimization is turned on in solrconfig.xml:
   <!-- An optimization that attempts to use a filter to satisfy a search.
         If the requested sort does not include score, then the filterCache
         will be checked for a filter matching the query. If found, the filter
         will be used as the source of document ids, and then the sort will be
         applied to that.  -->

> A more general question: Is all the CNet logic of intersecting bitsets
> available through the servlet or have I to write some java code to be
> plugged in Solr?

The nitty-gritty if getting intersection counts is in Solr, but you
still need to ask solr for each facet count individually, and you
still need to know which counts to ask for.  Thats the part you
currently still need a custom request handler for.

> In this case which is the correct level to make this, perhaps a new
> RequestHandler understanding some new query syntax to exploit filters.

Yes, a new RequestHandler.. from there the easiest way is to pass
extra parameters  (not changing the query syntax passed as "q").

> We only need a sort on a single and precalculated rank field stored as a
> range field, so we don't need relevance and consequently don't nedd scores
> (which is a prerequisite for using BitSets, if I understand well).

You can do relevancy scoring *and* do facets at the same time... there
is no incompatibility there.


View raw message