You could make these filter queries. Filters are a separate cache and as long as you have more cache than queries they will remain pinned in RAM. Your code has to remember these special queries in special-case code, and create dummy query strings to fetch the filter query. "field:[* TO *]" will do nicely.
Cheers, Lance Norskog -----Original Message----- From: Britske [mailto:[EMAIL PROTECTED] Sent: Thursday, October 04, 2007 1:38 PM To: solr-user@lucene.apache.org Subject: Re: how to make sure a particular query is ALWAYS cached hossman wrote: > > > : I want a couple of costly queries to be cached at all times in the > : queryResultCache. (unless I have a new searcher of course) > > first off: you can ensure that certain queries are in the cache, even > if there is a newSearcher, just configure a newSearcher Event Listener > that forcibly warms the queries you care about. > > (this is particularly handy to ensure FieldCache gets populated before > any user queries are processed) > > Second: if i understand correctly, you want a way to put an object in > the cache, and garuntee that it's always in the cache, even if other > objects are more frequetnly used or more recently used? > > that's kind of a weird use case ... can you elaborate a little more on > what exactly your end goal is? > > Sure. Actually i got the idea of another thread posted by Thomas to which you gave a reply a few days ago: http://www.nabble.com/Result-grouping-options-tf4522284.html#a12900630. I quote the relevant bits below, although I think you remember: hossman wrote: > > : Is it possible to use faceting to not only get the facet count but > also the > : top-n documents for every facet > : directly? If not, how hard would it be to implement this as an > extension? > > not hard ... a custom request handler could subclass > StandardRequestHandler, call super.handleRequest, and then pull the > field faceting info out of the response object, and fetch a DocList > for each of the top N field constraints. > I have about a dozen queries that I want to have permanently cached, each corresponding to a particular navigation page. Each of these pages has up to about 10 top-N lists which are populated as discussed above. These lists are pretty static (updated once a day, together with the index). The above would enable me to populate all the lists on a single page in 1 pass. Correct? Although I haven't tried yet, I can't imagine that this request returns in sub-zero seconds, which is what I want (having a index of about 1M docs with 6000 fields/ doc and about 10 complex facetqueries / request). The navigation-pages are pretty important for, eh well navigation ;-) and although I can rely on frequent access of these pages most of the time, it is not guarenteed (so neither is the caching) hossman wrote: > > the most straightforward approach i can think of would be a new cache > implementation that "permenantly" stores the first N items you put in it. > that in combination with the newSearcher warming i described above > should work. > > : 1. use User/Generic-cache. This would result in seperate coding-path > in > : application which I would like to avoid. > : 2. exend LRU-cache, and extend request-handler so that a query can > be > : extended with a parameter indicating that it should be cached at all > times. > : However, this seems like a lot of cluttering-up these interfaces, > for a > : relatively small change. > > #1 wouldn't really accomplish what you want without #2 as well. > > > > -Hoss > > > regarding #1. Wouldn't making a user-cache for the sole-purpose of storing these queries be enough? I could then reference this user-cache by name, and extract the correct queryresult. (at least that's how I read the documentation, I have no previous experience with the user-cache mechanism). In that case I don't need #2 right? Or is this for another reason not a good way to handle things? //Geert-Jan -- View this message in context: http://www.nabble.com/how-to-make-sure-a-particular-query-is-ALWAYS-cached-t f4566711.html#a13048285 Sent from the Solr - User mailing list archive at Nabble.com.
