My bet, but only bet, is that you'll pointlessly create garbage in your
heap for bitsets that might have gc pressure, eg but is filter is quite
selective you'll have rather compact SortedIntDocSet that would not be so
sensible.
"To avoid impact on rating" I can propose you boost that clause quite l
Would you still have performance impact if you set to no cache and just use
fq to avoid impact on rating ?
On Dec 11, 2012 7:00 PM, "Mikhail Khludnev"
wrote:
> It's worth to mention that fq is profitable only if you have high hit ratio
> and proper filterCache size. If you see low hit ratio you j
It's worth to mention that fq is profitable only if you have high hit ratio
and proper filterCache size. If you see low hit ratio you just waste
resources on it.
11.12.2012 8:24 пользователь "Otis Gospodnetic"
написал:
> If you don't need scoring on it then yes, just use fq.
>
> Otis
> --
> SOLR
If you don't need scoring on it then yes, just use fq.
Otis
--
SOLR Performance Monitoring - http://sematext.com/spm/index.html
On Mon, Dec 10, 2012 at 10:34 PM, Floyd Wu wrote:
> Thanks Otis.
>
> When talked about query performance(ignore scoring). To use fq is better?
>
> Floyd
>
>
> 2012
Thanks Otis.
When talked about query performance(ignore scoring). To use fq is better?
Floyd
2012/12/11 Otis Gospodnetic
> Hi,
>
> The fq one is a FilterQuery that only does matching, but not scoring. It's
> results are stored in the filter cache, while the q uses the query cache.
>
> Otis
>
Hi,
The fq one is a FilterQuery that only does matching, but not scoring. It's
results are stored in the filter cache, while the q uses the query cache.
Otis
--
SOLR Performance Monitoring - http://sematext.com/spm/index.html
On Mon, Dec 10, 2012 at 10:11 PM, Floyd Wu wrote:
> Hi There,
>
