Description
from the dev@lucene list...
Subject: Re: Performance hit of Solr checkIntegrityAtMerge
There are two costs: cpu and i/o.
The cpu cost is not much anyway but can be made basically trivial by
using java 8.
The i/o cost is because the check is not done with any i/o locality to
the data being merged. so it could be a perf hit for an extremely
large merge.In 5.0 the option is removed: we reworked this computation in merging
to always have locality and so on, the checking always happens.
...but on the 5x branch, the checkIntegrityAtMerge setting (and comments) still exist in the example configs, and the SolrIndexConfig code still parses it (but does nothing with it since IWC no longer accepts it as an option)
todo..
- remove setting form example configs (runk & 5x)
- update code to check if the setting is used & log a warning that it's now ignored
- backport this to 5x
- update code (trunk only) to completely remove parsing of this setting
Attachments
Attachments
Issue Links
- relates to
-
LUCENE-5969 Add Lucene50Codec
- Closed