Given that the filters being cached are useful across all these
contexts, and that facet values are often subsequently applied as
filters, I don't think it'd make sense to separate these two --
especially not without some way to have both aware of each other to
avoid duplicating effort.
It might be good to have a more specific sense of the problems
involved -- workload, cache size, etc. Because of the potential
downstream consequences (for performance, cache usage patterns, etc.)
here, if this can be solved by simply increasing the size of the
cache, I'd go that route first for sure.
I do think that the docs filterCache refguide [1] could be updated to
be more explicit about all the possible cases that use the
filterCache, and I'd be happy to help with that. But I think
super-high-level I'd start by trying to size filterCache according to
what it _actually_ uses, rather than size it according to what I think
it _should_ use and then adjust the underlying implementation to
conform to that.
I've also idly considered a "named cache" variant of the
`filter(query)` context -- something like `namedFilter(cacheName,
query)` -- that would allow more fine-grained control over where
queries hit. I also have some thoughts about possible clean ways to
have multiple coordinated caches of compatible type -- but that'd be
farther out.
Short-term for your use case, it occurs to me that it'd be relatively
straightforward to write a QParserPlugin that consults a specific
named cache; then you could replace all `fq=query` with
`fq={!myFilterQuery cacheName=name v=$query}` and I think get the
behavior you're seeking. Would want to make the outer query return
false for `getCache()`, unless you want the query stored in both
filterCache _and_ your named cache!
Michael
[1]
https://solr.apache.org/guide/solr/latest/configuration-guide/caches-warming.html#filter-cache
On Thu, Nov 17, 2022 at 1:57 PM Mikhail Khludnev <m...@apache.org> wrote:
>
> > whether DocList can even be used for facets,
> No way. For sure.
>
> Overall, FacetComponent explicitly requires docset
> https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/handler/component/FacetComponent.java#L82
> and then
> https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/search/SolrIndexSearcher.java#L1564
> https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/search/SolrIndexSearcher.java#L971
> I don't recommend changing anything in this flow.
>
>
> On Thu, Nov 17, 2022 at 9:05 PM Shawn Heisey <apa...@elyograg.org> wrote:
>
> > On 11/17/22 08:45, Andy Lester wrote:
> > > Short of that, wouldn't it make sense for facets to put the q in the
> > queryResultsCache, not the filterCache?
> >
> > The queryResultCache is defined as <QueryResultKey,DocList> ... very
> > different from the <Query,DocSet> that filterCache uses. I have no idea
> > whether DocList can even be used for facets, but it is likely that
> > DocSet is faster and more directly applicable. Because filterCache was
> > already available, a choice was probably made to just use that rather
> > than introduce a whole new cache.
> >
> > That decision is a bad one for your use case. Having a separate
> > facetCache seems like a very good thing for your use case and probably
> > would be generally helpful for overall performance in a variety of use
> > cases.
> >
> > That part of Solr code is very unfamiliar to me, I wouldn't have any
> > idea where to begin or what to do for implementing facetCache. I would
> > tackle it if I knew how.
> >
> > Thanks,
> > Shawn
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> > For additional commands, e-mail: dev-h...@solr.apache.org
> >
> >
>
> --
> Sincerely yours
> Mikhail Khludnev
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org
