>
> 1) The merge factor only applies to our existing merge policies. I.e. if
> someone registers a custom merge policy which looks at other parameters but
> does not care about segment sizes at the same level, this parameter is
> useless.
>
OK so I see the code handles it by logging a warning message:
} else if (mergeFactor != -1) {
log.warn("Use of <mergeFactor> cannot be configured if merge policy
is not an instance of LogMergePolicy or TieredMergePolicy. The configured
policy's defaults will be used.");
}
But still, I think it's better if it is a merge policy parameter. Then
users don't even have to wonder why they see these messages in the log.
Shai
On Tue, Jul 29, 2014 at 1:41 PM, Shai Erera <[email protected]> wrote:
> Hi
>
> While reading the IndexConfig section in the Solr ref guide, I noticed
> that mergeFactor is exposed as its own <mergeFactor> element, and not a
> merge policy parameter, e.g. <int name="mergeFactor">10</int>. I think
> that's wrong because:
>
> 1) The merge factor only applies to our existing merge policies. I.e. if
> someone registers a custom merge policy which looks at other parameters but
> does not care about segment sizes at the same level, this parameter is
> useless.
>
> 2) SolrIndexConfig has redundant code if the default MP is used
> (TieredMP), it sets segsPerTier to mergeFactor.
>
> 3) And if the user defines both mergeFactor and segsPerTier, then the
> second one wins (by current code).
>
> But I think this should just be a merge policy setting, and if you are
> using TieredMP, you should use the settings that come with it, i.e
> segsPerTier and not have a weird mapping from mergeFactor to it.
>
> In terms of backwards compatibility, we can declare the standalone element
> deprecated, continue to respect it in 4.x and remove it in 5.0.
>
> Before I open an issue to address it, I wanted to make sure though that
> there isn't a good reason for why it is like that today..
>
> Shai
>
