lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anria B." <anria_o...@yahoo.com>
Subject Re: &fq degrades qtime in a 20million doc collection
Date Sat, 16 Jan 2016 01:48:44 GMT
hi Yonik

We definitely didn't overlook that q=* being a wildcard scan, we just had so
many systemic problems to focus on I neglected to thank Shawn for that
particular piece of useful information. 

I must admit, I seriously never knew this. Ever since q=* was allowed I was
so happy that it never occurred to me to investigate its details.   Now I
know :)

Combining all the information from everybody here really brought home where
our shortcomings were

1. yes, the q=* was quickly replaced by q=*:* everywhere - quick win
2. caching strategies are being reformed 
3. We're looking into making smaller shards / cores since we do require
super frequent commits, so on smaller bitsets the commit times should be way
less, and we can use the smaller heap sizes to stay optimized in that realm

One last question though please :

Schema investigations :  the &fq are frequently on Multivalued string
fields, and we believe that it may also be slowing down the &Fq even more,
but we were wondering why.   When we run &fq on single valued fields its
faster than the multi-valued fields, even when the multi-valued fields
frequently have only a single value in it.

Thanks again for everybody's help and pointers and hints, you kept us busy
with changing our mindset on a lot of things here.

Regards
Anria



--
View this message in context: http://lucene.472066.n3.nabble.com/fq-degrades-qtime-in-a-20million-doc-collection-tp4250567p4251212.html
Sent from the Solr - User mailing list archive at Nabble.com.

Mime
View raw message