-
Notifications
You must be signed in to change notification settings - Fork 1.4k
GITHUB#14399: decide index-sort early termination per segment in TopFieldCollector #16434
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
Open
serhiy-bzhezytskyy
wants to merge
4
commits into
apache:main
Choose a base branch
from
serhiy-bzhezytskyy:GITHUB-14399-topfieldcollector-per-leaf-indexsort
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from 3 commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
673544c
GITHUB#14399: decide index-sort early termination per segment in TopF…
sergeybzhezitskiy f150ad9
GITHUB#14399: drop the merge scheduler from the new test
serhiy-bzhezytskyy 14c116b
GITHUB#14399: move the CHANGES entries to 10.6
serhiy-bzhezytskyy 362bd8a
GITHUB#14399: the test comments still described the cached decision
serhiy-bzhezytskyy File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -27,8 +27,11 @@ | |
| import org.apache.lucene.document.Field.Store; | ||
| import org.apache.lucene.document.NumericDocValuesField; | ||
| import org.apache.lucene.document.StringField; | ||
| import org.apache.lucene.index.DirectoryReader; | ||
| import org.apache.lucene.index.IndexReader; | ||
| import org.apache.lucene.index.IndexWriterConfig; | ||
| import org.apache.lucene.index.LeafReaderContext; | ||
| import org.apache.lucene.index.MultiReader; | ||
| import org.apache.lucene.index.SerialMergeScheduler; | ||
| import org.apache.lucene.index.Term; | ||
| import org.apache.lucene.search.IndexSearcher.LeafReaderContextPartition; | ||
|
|
@@ -41,6 +44,7 @@ | |
| import org.apache.lucene.tests.util.LuceneTestCase; | ||
| import org.apache.lucene.tests.util.TestUtil; | ||
| import org.apache.lucene.util.Bits; | ||
| import org.apache.lucene.util.IOUtils; | ||
|
|
||
| public class TestTopFieldCollectorEarlyTermination extends LuceneTestCase { | ||
|
|
||
|
|
@@ -264,4 +268,86 @@ public void testCanEarlyTerminateOnPrefix() { | |
| new SortField("c", SortField.Type.LONG), | ||
| new SortField("b", SortField.Type.STRING)))); | ||
| } | ||
|
|
||
| /** | ||
| * GITHUB#14399: TopFieldCollector caches whether the search sort is a prefix of the index sort | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This comment is outdated now, I think? |
||
| * after inspecting only the first leaf. That is safe for a single index (IndexWriter enforces one | ||
| * index sort), but a MultiReader can span indexes with different index sorts. Here the first | ||
| * index is sorted so the search sort IS a prefix (early termination is eligible) while the second | ||
| * index is sorted the opposite way (it is NOT). The cached "yes" wrongly early-terminates the | ||
| * second leaf and drops results that should rank first. | ||
| */ | ||
| public void testMultiReaderWithDifferentIndexSorts() throws IOException { | ||
| final Sort ascSort = new Sort(new SortField("ndv", SortField.Type.LONG)); | ||
|
|
||
| // Index A: sorted ndv ASC, many docs with a moderate value (50). Under an ASC search sort this | ||
| // leaf is prefix-sorted, so the collector caches "search sort is part of index sort" = true and | ||
| // calls disableSkipping(). | ||
| Directory dirA = newDirectory(); | ||
| IndexWriterConfig iwcA = newIndexWriterConfig().setIndexSort(ascSort); | ||
| try (RandomIndexWriter w = new RandomIndexWriter(random(), dirA, iwcA)) { | ||
| for (int i = 0; i < 20; i++) { | ||
| Document doc = new Document(); | ||
| doc.add(new NumericDocValuesField("ndv", 50L)); | ||
| w.addDocument(doc); | ||
| } | ||
| w.forceMerge(1); | ||
| } | ||
|
|
||
| // Index B: sorted ndv DESC (a DIFFERENT index sort). Its most competitive doc for an ASC search | ||
| // (value 1) is written LAST, so in docid order the leaf is [90, 90, ..., 1]. If leaf B is | ||
| // wrongly | ||
| // treated as prefix-sorted (leaf A's cached decision), collection terminates in docid order | ||
| // after | ||
| // the threshold and never reaches the trailing value 1 -- the true top result is dropped. | ||
| Directory dirB = newDirectory(); | ||
| IndexWriterConfig iwcB = | ||
| newIndexWriterConfig() | ||
| .setIndexSort(new Sort(new SortField("ndv", SortField.Type.LONG, true))); | ||
| try (RandomIndexWriter w = new RandomIndexWriter(random(), dirB, iwcB)) { | ||
| for (int i = 0; i < 20; i++) { | ||
| Document doc = new Document(); | ||
| doc.add(new NumericDocValuesField("ndv", 90L)); | ||
| w.addDocument(doc); | ||
| } | ||
| Document winner = new Document(); | ||
| winner.add(new NumericDocValuesField("ndv", 1L)); // the smallest value overall | ||
| w.addDocument(winner); | ||
| w.forceMerge(1); | ||
| } | ||
|
|
||
| DirectoryReader readerA = DirectoryReader.open(dirA); | ||
| DirectoryReader readerB = DirectoryReader.open(dirB); | ||
| // MultiReader with A first, so the first leaf is the ASC-sorted one (search sort is a prefix -> | ||
| // eligible for early termination); the B leaf is DESC-sorted (not a prefix). | ||
| MultiReader multiReader = new MultiReader(readerA, readerB); | ||
| try { | ||
| // Force both leaves into a single slice so one collector (with one shared | ||
| // searchSortPartOfIndexSort cache) sees both the ASC-sorted and DESC-sorted leaves. | ||
| IndexSearcher searcher = | ||
| new IndexSearcher(multiReader) { | ||
| @Override | ||
| protected LeafSlice[] slices(List<LeafReaderContext> leaves) { | ||
| List<LeafReaderContextPartition> partitions = new ArrayList<>(); | ||
| for (LeafReaderContext ctx : leaves) { | ||
| partitions.add(LeafReaderContextPartition.createForEntireSegment(ctx)); | ||
| } | ||
| return new LeafSlice[] {new LeafSlice(partitions)}; | ||
| } | ||
| }; | ||
| // numHits=1, threshold=1: want the single smallest value overall, which is 1 (last docid of | ||
| // leaf B). Correct answer is 1; the bug drops it and returns 50 (from leaf A). | ||
| TopFieldCollectorManager manager = new TopFieldCollectorManager(ascSort, 1, null, 1); | ||
| TopFieldDocs td = searcher.search(new MatchAllDocsQuery(), manager); | ||
|
|
||
| assertEquals(1, td.scoreDocs.length); | ||
| long topValue = (long) ((FieldDoc) td.scoreDocs[0]).fields[0]; | ||
| assertEquals("the smallest value (1, trailing docid of leaf B) must win", 1L, topValue); | ||
| } finally { | ||
| multiReader.close(); | ||
| readerA.close(); | ||
| readerB.close(); | ||
| IOUtils.close(dirA, dirB); | ||
| } | ||
| } | ||
| } | ||
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 nice to use Sort.getPrimarySortField() here but I think that's going to end up being fairly complex in its interaction with sort prefixes, so we can leave that for a follow-up.
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.
Agreed on leaving it for a follow-up.
canEarlyTerminatecompares the full prefix, so a primary-field shortcut would have to keep the same answer for multi-field sorts — worth its own change with its own tests.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.
Measured it since: substituting the shortcut into
canEarlyTerminateOnPrefixreturns a wrong result — an index sorted(a, c)searched by(a, b)gives the wrong top hit, because documents with equalaare ordered bycso theirborder is arbitrary.testCanEarlyTerminateOnPrefixalready asserts false for that shape. So the follow-up isn't needed here — the full prefix comparison is load-bearing.