lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kaktu Chakarabati <>
Subject MM Parameter and Performance in Solr
Date Fri, 05 Jun 2009 02:30:10 GMT
Hey guys,
I've been noticing for quite a long time that using minmatch parameter with
a value less than 100%
alongside the dismax qparser seriously degrades performance. My particular
use case involves
using dismax over a set of 4-6 textual fields, about half of which do *not*
filter stop words. ( so yes,
these do involve iterating over large portion of my index in some cases).

This is somewhat understandable as the task of constructing result sets is
no longer simply intersection based,
however I do wonder what work-arounds / standard solutions exist for this
problem and which are applicable
in the solr/lucene environment ( I.e dividing index to 'primary' /
'secondary' sections, using n-gram indices, caching configuration, sharding
might help..? )
I'm working with not such a large corpus (~20 million documents) and the
query processing time is way too long
to my mind ( my goal is 90% percentile QTime to hit around 200ms, I can say
that currently its more than double that.. )
Can anyone please share some of his knowledge? what is practiced i.e in
google, yahoo..? Any plans to address these issue in solr/lucene or am
i just using it wrongly?

Any feedback appreciated..


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message