I think a new issue is appropriate, not the old one SOLR-1617 that feels like the reporter's wishful TODO that is underspecified.
FYI on your implementation consider that Solr has some existing per-segment caches; one somewhere in the joins perSegment blah blah blah, and another inside RptWithGeometrySpatialField. It's a bit awkward; I wish Solr supported per-segment caches better as a first class notion. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Wed, Jul 24, 2019 at 9:57 AM Michael Gibney <mich...@michaelgibney.net> wrote: > I'm interested in caching facet counts, keyed to query/DocSet domain (like > filterCache, but caching facet counts instead of DocSets). > > Trying not to open a duplicate issue, I found SOLR-1617 > <https://issues.apache.org/jira/browse/SOLR-1617>, but I wasn't clear on > whether it's applicable, or whether it's about maintaining per-segment UIF > data structures (which could be considered a type of cache). > > I'd appreciate any guidance/suggestions on how to proceed -- revive > SOLR-1617, or open a new issue; thanks! > > Michael > > ps- A version of the functionality I'm interested in is implemented and > folded in to SOLR-13132 <https://issues.apache.org/jira/browse/SOLR-13132> (as > a prerequisite for performance on that issue). But I think I may have > buried the lead by including it there, since sort-by-relatedness is a > relatively specialized use case, and a facet cache is more generally > useful. The cache as implemented for SOLR-13132 is compatible across > SimpleFacets and JSON facets, and is segment-aware (so should be > NRT-friendly). It's particularly useful for high-cardinality fields and > high-cardinality DocSet domains (e.g., facets on a main landing page). >
