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 otis.gospodne...@gmail.com
написал:
If you don't need scoring on it then yes, just use
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 mkhlud...@griddynamics.com
wrote:
It's worth to mention that fq is profitable only if you have high hit ratio
and proper filterCache size. If you
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
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 floyd...@gmail.com
Thanks Otis.
When talked about query performance(ignore scoring). To use fq is better?
Floyd
2012/12/11 Otis Gospodnetic otis.gospodne...@gmail.com
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
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 floyd...@gmail.com wrote:
Thanks Otis.
When talked about query performance(ignore scoring). To use fq is better?
