> In my own Solr 1.4, I am pretty sure that running an index optimize does > give me significant better performance. Perhaps because I use some > largeish (not huge, maybe as large as 200k) stored fields.
200.000 stored fields? I asume that number includes your number of documents? Sounds crazy =) > > So I'm interested in always keeping my index optimized. > > Am I right that if I set mergeFactor to '1', essentially my index will > always be optimized after every commit, and actually running 'optimize' > will be redundant? You can set mergeFactor to 2, not lower. > > What are the possible negative repurcussions of setting mergeFactor to > 1? Is this a really bad idea? If not 1, what about some other > lower-than-usually-recommended value like 2 or 3? Anyone done this? > I imagine it will slow down my commits, but if the alternative is > running optimize a lot anyway.... I wonder at what point I get 'break > even' (if I optimize after every single commit, clearly might as well > just set the mergeFactor low, right? But if I optimize after every X > documents or Y commits.... don't know what X/Y are break-even). This depends on commit rate and if there are a lot of updates and deletes instead of adds. Setting it very low will indeed cause a lot of merging and slow commits. It will also be very slow in replication because merged files are copied over again and again, causing high I/O on your slaves. There is always a `break even` but it depends (as usual) on your scenario and business demands. > > Jonathan
