Reitzel, Charles <charles.reit...@tiaa-cref.org> wrote: > Is there really a good reason to consolidate down to a single segment?
In the scenario spawning this thread it does not seem to be the best choice. Speaking more broadly there are Solr setups out there that deals with immutable data, often tied to a point in time, e.g. log data. We have such a setup (harvested web resources) and are able to lower heap requirements significantly and increase speed by building fully optimized and immutable shards. > Any incremental query performance benefit is tiny compared to the loss of > managability. True in many cases and I agree that the "Optimize"-wording is a bit of a trap. While technically correct, it implies that one should do it occasionally to keep any index fit. A different wording and maybe a tooltip saying something like "Only recommended for non-changing indexes" might be better. Turning it around: To minimize the risk of occasional performance-degrading large merges, one might want an index where all the shards are below a certain size. Splitting larger shards into smaller ones would in that case also be an optimization, just towards a different goal. - Toke Eskildsen
