Hi, If your mergeFactor is "reasonable" (e.g. default 10), Lucene will keep the number of segments in the index under control. Your index will not be optimized at all times, but the number of segments will not be astronomical and not having a single-segment (i.e. optimized) index will not cause you headaches. I have some large indices over at simpy.com and I *never* optimize them. They grow and shrink as new docs are added to them, but never explode.
Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch ----- Original Message ---- > From: fireofenigma <[EMAIL PROTECTED]> > To: solr-user@lucene.apache.org > Sent: Tuesday, February 19, 2008 6:30:34 PM > Subject: Search Performance When There Are Many Segments > > > Let me start with an example application/scenario. > > I have an application that allows users to upload their documents that will > eventually be added to the index. Every 10 documents, I commit(). Do I ever > need to make a call to optimize() to optimize the index or does Solr have a > default behavior when to call optimize()? Regardless, if optimize() never > gets called after say 1000 calls to commit() with each commit adding 10 > documents to the index, does that have an adverse effect to the search > speed? > > Let's assume I'm using a compound-file index. > > Any insight is greatly appreciated. Thanks! > -- > View this message in context: > http://www.nabble.com/Search-Performance-When-There-Are-Many-Segments-tp15578740p15578740.html > Sent from the Solr - User mailing list archive at Nabble.com. > >
