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.
