> It seems reasonable to me. To count facets Solr needs docsets of results
> for in-order processing.
> I suppose, SimpleFacets code can be amended so it keeps the result docset
> out of filter cache, but would it get significant gain?

Mostly I think this is about expectations, and perhaps this is just about 
things that need to be explained more in the docs.

If I see "filter cache" I expect that to be FQs. I don't expect to see my 
q=whatever in the filter cache.

When I'm planning my filter cache, I would expect that the size of the filter 
cache should be the number of possible FQs that I'm going to call, if possible. 
If my app only has about 50 FQs possible, I'd think I only need to have to 
allocate a filter cache of maybe 100.  But that's not the case. Since every 
search (1000s/hr) a user does in the app does uses faceting, then every search 
throws a new entry into the filter cache.

The docs for facet.method=enum make it clear that "faceting on a field with 
U.S. States such as Alabama, Alaska, …​ Wyoming would lead to fifty cached 
filters which would be used over and over again. The filterCache should be 
large enough to hold all the cached filters."  OK, that's good and makes sense, 
but then I only need to allocate 50 more slots in the filter cache for that. 
With the caching of the q=whatever, then it's entirely different planning.

I just realized that the filterCache docs say "Solr also uses this cache for 
faceting when the configuration parameter facet.method is set to fc." from 
which I infer that facet.method=enum does not use the filter cache. But it does.

> Why do you think that thousands of evictions is a bad thing?

It's not bad, it's surprising. It's something I need to account for when 
planning and tuning.

I'm imagining pulling together a section in the filter cache docs explaining 
"Here's everything that can go into the filter cache". If I knew enough about 
the Solr code, I'd do it all myself, but I don't.

Anyone want to help on this endeavor?

Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org

Reply via email to