That's right. mergeFactor=1 is an even more extreme case. However, with the new per-segment readers, having an optimized index is no longer the best index state to go for in some cases.
Otis -- Sematext is hiring -- http://sematext.com/about/jobs.html?mls Lucene, Solr, Nutch, Katta, Hadoop, HBase, UIMA, NLP, NER, IR ----- Original Message ---- > From: Lance Norskog <goks...@gmail.com> > To: solr-user@lucene.apache.org > Sent: Monday, September 28, 2009 2:42:29 PM > Subject: Re: Writing optimized index to different storage? > > The optimize operation happens in place. > > I've been told that if you set "mergeFactor=2" when indexing, it will > be slower but you will always have a "mostly optimized" index. > > On Mon, Sep 28, 2009 at 10:22 AM, Jason Rutherglen > wrote: > > Hmm... Interesting question, not that I know of. The only way > > one could do this would be to intercept the newly optimized > > files via a FileSwitchDirectory like implementation that knows > > which new files are optimized and should "underneath" go to a > > different physical path. > > > > On Mon, Sep 28, 2009 at 7:57 AM, Phillip Farber wrote: > >> > >> Is it possible to tell Solr or Lucene, when optimizing, to write the files > >> that constitute the optimized index to somewhere other than > >> SOLR_HOME/data/index or is there something about the optimize that requires > >> the final segment to be created in SOLR_HOME/data/index? > >> > >> Thanks, > >> > >> Phil > >> > >> > > > > > > -- > Lance Norskog > goks...@gmail.com
