I think you would probably want to control the number of segments with the MapReduceIndexerTool before doing the merge initially, and if you find you have too many segments over time as you add more and more data, use a force merge call to reduce the number segments, either manually or scheduled.
-- Mark Miller about.me/markrmiller On July 11, 2014 at 4:36:22 PM, Erick Erickson ([email protected]) wrote: > I think I've become aware of an edge case that I'm wondering is worth > a JIRA. Say I have a mergeFactor of 2. Now say I create a bunch of > indexes and add them one by one to the running Solr node via merge > indexes. The mergeFactor appears to be ignored in this scenario. > Indeed, I suspect (without proof) that the entire merge policy is > never referenced at all. > > Historically this hasn't mattered, since merging indexes was > 1> a rare operation > 2> the merge policy _does_ kick in when the index has more documents > added to it via the normal (not merge indexes) policy so things would > be cleaned up. > > All that said, the mapReduceIndexerTool is a scenario where we may be > merging multiple times without every indexing documents any other way. > Seems like the core admin API should trigger the merge policy logic > somehow. The problem here is that the number of segments can grow > without bound. > > Worth a JIRA? > > Erick > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
