[
https://issues.apache.org/jira/browse/JCR-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545851
]
Ard Schrijvers commented on JCR-1238:
-------------------------------------
Performance drops indeed almost linearly when the number of indexes grow very
large. OTOH, merging very large indexes also means loosing possibly very large
hierarchical caches (which we just hopefully fixed :-)). I agree on setting it
to Integer.MAX_VALUE, but I think I would personally use values around
1.000.000. I'd like to have some configuration thing or some hook/trigger
which could say to optimize and merge all (at startup or at some point in time
which i might control myself).
> Change default value for maxMergeDocs
> -------------------------------------
>
> Key: JCR-1238
> URL: https://issues.apache.org/jira/browse/JCR-1238
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-core
> Reporter: Marcel Reutegger
> Priority: Minor
>
> This is actually a left over from the time before JCR-197 was implemented.
> Back then index merges were performed with the client thread and would hold
> up execution for a long time if a large number of nodes were merged. The
> default value for maxMergeDocs limited this to 100'000 nodes, resulting in a
> couple of seconds for the merge operation.
> This default value does not make sense anymore because index merges are
> performed in a background thread and may take a long time without an effect
> on regular workspace operations. If a workspace grows large it may cause
> performance degradation because the number of index segments increases
> linearly when there are more than 100'000 nodes.
> I propose to set the new default to Integer.MAX_VALUE
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
