Hi, Andy.
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?
Why do you think that thousands of evictions is a bad thing?

On Wed, Nov 16, 2022 at 8:26 PM Andy Lester <a...@petdance.com> wrote:

> I've been working on tuning my filter cache, and have discovered that
> doing a search with facet=on results in an entry in the filter cache for
> the q parameter. This makes no sense to me. Is this intentional?
>
> In my app, there are only a couple of dozen possible FQs that can get
> passed to Solr. There are no restrictions on the Q. The result is that I
> have many added keys to the filter cache, and many evictions. I should be
> able to get by with a filterCache size of 100, but even with a filterCache
> size of 5000 I get thousands of evictions per hour because of all the
> unique Q arguments getting added.
>
> If it is intentional, then we need to update the docs for both faceting
> and the filter cache to explain the behavior. This is something that users
> will need to take in to account when planning and tuning caches.
>
> If this behavior is not intentional and is a bug, it seems like fixing it
> would be an easy performance win.
>
> I've made a ticket for this at
> https://issues.apache.org/jira/browse/SOLR-16546  It illustrates the
> specific steps I've taken to demonstrate the behavior. The demonstration is
> on Solr 9.0.0 and uses Shawn Heisey's filter cache dumper for illustration,
> but it also happens on a stock 8.11.2 install.
>
> Thanks,
> Andy
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
>
>

-- 
Sincerely yours
Mikhail Khludnev

Reply via email to