lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Rochkind <>
Subject RE: Disabling caching for fq param?
Date Tue, 01 Mar 2011 03:09:23 GMT
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 []
Sent: Monday, February 28, 2011 9:06 PM
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>

...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?


View this message in context:
Sent from the Solr - User mailing list archive at

View raw message