Gregg, The QueryResultCache caches a sorted int array of results matching the a query. This should overlap very nicely with your desired behavior, as a hit in this cache will not perform a Lucene query nor a need to calculate score.
Now, ‘for the life of the Searcher’ is the trick here. You can size your cache large enough to ensure it can fit every possible query, but at some point this is untenable. I would argue that high volatility of query parameters would invalidate the need for caching anyway, but that’s clearly debatable. Nevertheless, this should work admirably well to solve your needs. Jason On Feb 18, 2014, at 11:32 AM, Gregg Donovan <gregg...@gmail.com> wrote: > We're testing out a new handler that uses edismax with three different > "boost" functions. One has a random() function in it, so is not very > cacheable, but the other two boost functions do not change from query to > query. > > I'd like to tell Solr to cache those boost queries for the life of the > Searcher so they don't get recomputed every time. Is there any way to do > that out of the box? > > In a different custom QParser we have we wrote a CachingValueSource that > wrapped a ValueSource with a custom ValueSource cache. Would it make sense > to implement that as a standard Solr function so that one could do: > > boost=cache(expensiveFunctionQuery()) > > Thanks. > > --Gregg