I need the documents in order, so FilterCache is no use. Moreover, I already use lots of the filtercache for other fq-queries. About 99% of the 6000 fields I mentioned have there values seperately in the filtercache. There must be room for optimization there, but that's a different story ;-)
//Geert-Jan Lance Norskog wrote: > > 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. > > > -- View this message in context: http://www.nabble.com/how-to-make-sure-a-particular-query-is-ALWAYS-cached-tf4566711.html#a13050087 Sent from the Solr - User mailing list archive at Nabble.com.
