RE: Disabling caching for fq param?
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= > &fq=labels: > &qf= > &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.
Re: Disabling caching for fq param?
We use fq params for filtering as well (not show in previous example), so we
only want to be able to override fq caching on a per-parameter basis (e.g.,
fq={!noCache userLabels} ).
Thanks
Markus Jelsma-2 wrote:
>
> If filterCache hitratio is low then just disable it in solrconfig by
> deleting
> the section or setting its values to 0.
>
>> 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=
>> &fq=labels:
>> &qf=
>> &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-tp2600188p2602986.html
Sent from the Solr - User mailing list archive at Nabble.com.
Re: Disabling caching for fq param?
If filterCache hitratio is low then just disable it in solrconfig by deleting the section or setting its values to 0. > 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= > &fq=labels: > &qf= > &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!
RE: Disabling caching for fq param?
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= &fq=labels: &qf= &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.
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= &fq=labels: &qf= &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.
