-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Switching to a fixed CFS threshold #15295
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
| } | ||
|
|
||
| // Apply appropriate threshold based on merge policy type | ||
| if (mergePolicy instanceof LogDocMergePolicy) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be great if we can avoid customizing it for specific policies, otherwise it might be tricky to maintain in the future, if e.g. there is another policy that is based on doc size not bytes.
Maybe we can add a enum and a method to MergePolicy which returns its unit (bytes/docs) , and use it here to decide which threshold to use?
Or do we want to always choose compound format based on size in bytes even for LogDocMergePolicy? In this case we might be able to use merge.getMergeInfo().sizeInBytes() when we call this method and avoid relying on MergePolicy#size all together?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 to the idea of Enums, I will wait if anyone else has other suggestions here but having an enum makes most sense to me.
|
This PR has not had activity in the past 2 weeks, labeling it as stale. If the PR is waiting for review, notify the dev@lucene.apache.org list. Thank you for your contribution! |
stefanvodita
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had looked at this PR before, but I see it's gone stale. Hoping to revive it.
Surprised how many changes we needed for this!
lucene/core/src/java/org/apache/lucene/index/LiveIndexWriterConfig.java
Outdated
Show resolved
Hide resolved
lucene/core/src/test/org/apache/lucene/index/TestAddIndexes.java
Outdated
Show resolved
Hide resolved
lucene/test-framework/src/java/org/apache/lucene/tests/util/LuceneTestCase.java
Show resolved
Hide resolved
stefanvodita
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for addressing my comments! There are two questions left for me from the comments:
- Whether the thresholds we're starting with are good enough for a first iteration.
- Whether we can avoid branching logic based on which merge policy is in use.
| * MergePolicy#setNoCFSRatio(double)} and {@link MergePolicy#setMaxCFSSegmentSizeMB(double)}. This | ||
| * setting only applies to newly created segments.</b> | ||
| * <p><b>Note: To control compound file usage during segment merges. More here: | ||
| * lucene/core/src/java/org/apache/lucene/codecs/CompoundFormat.java</b> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we use the @link syntax?
Problem
Lucene uses CFS ratio (which is by default 10%) to determine whether to use Compound Files.
Solution
In this PR we are doing the following:
Switching from a CFS ratio to a fixed threshold which is:
Moved CFS configuration to CompoundFormat.java from Merge policies.
Fixes #14959