That clause will always be the same per-user (i.e., you have values 1,2,4 and I have values 1,2,8) across queries. In the result set denoted by the labels param, some users will have tens of thousands of documents and others will have millions of documents.
It sounds like you don't see a huge problem with our approach, so maybe we'll stick with it for the time being. Thanks! Jonathan Rochkind wrote: > > As far as I know there is not, it might be beneficial, but also worth > considering: "thousands" of users isn't _that_ many, and if that same > clause is always the same per user, then if the same user does a query a > second time, it wouldn't hurt to have their user-specific fq in the cache. > A single fq cache may not take as much RAM as you think, you could > potentially afford increase your fq cache size to > thousands/tens-of-thousands, and win all the way around. > > The filter cache should be a least-recently-used-out-first cache, so even > if the filter cache isn't big enough for all of them, fq's that are used > by more than one user will probably stay in the cache as old user-specific > fq's end up falling off the back as least-recently-used. > > So in actual practice, one way or another, it may not be a problem. > ________________________________________ > From: mrw [mikerobertsw...@gmail.com] > Sent: Monday, February 28, 2011 9:06 PM > To: solr-user@lucene.apache.org > Subject: Disabling caching for fq param? > > Based on what I've read here and what I could find on the web, it seems > that > each fq clause essentially gets its own results cache. Is that correct? > > We have a corporate policy of passing the user's Oracle OLS labels into > the > index in order to be matched against the labels field. I currently > separate > this from the user's query text by sticking it into an fq param... > > ?q=<user-entered expression> > &fq=labels:<the label values expression> > &qf=<song metadata copy field> <song lyrics field> > &tie=0.1 > &defType=dismax > > ...but since its value (a collection of hundreds of label values) only > apply > to that user, the accompanying result set won't be reusable by other > users: > > My understanding is that this query will result in two result sets (q and > fq) being cached separately, with the union of the two sets being returned > to the user. (Is that correct?) > > There are thousands of users, each with a unique combination of labels, so > there seems to be little value in caching the result set created from the > fq > labels param. It would be beneficial if there were some kind of fq > parameter override to indicate to Solr to not cache the results? > > > Thanks! > > > > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/Disabling-caching-for-fq-param-tp2600188p2600188.html > Sent from the Solr - User mailing list archive at Nabble.com. > > -- View this message in context: http://lucene.472066.n3.nabble.com/Disabling-caching-for-fq-param-tp2600188p2603009.html Sent from the Solr - User mailing list archive at Nabble.com.
