-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
Cut over from SearchContext to ReaderContext #51282
Cut over from SearchContext to ReaderContext #51282
Conversation
Pinging @elastic/es-search (:Search/Search) |
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 left one question and an idea for a possible simplification. Other than that the pr looks great and we can try to optimize the parsing in a follow up (lazy rewrite of the query in the fetch phase for instance).
/** | ||
* This life time is for objects that need to live until the end of the current search phase. | ||
*/ | ||
PHASE, |
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 think we can remove Lifetime
entirely. We don't use COLLECTION
so it would be easier to just call addReleasable(Releasable)
.
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 removed it in 34ed39b.
private final ShardSearchRequest request; | ||
private final ScrollContext scrollContext; | ||
private AggregatedDfs aggregatedDfs; | ||
private List<RescoreContext> rescore; |
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.
Why do you need to keep the rescorers ? Can't we build them on each phase like we do for the Query
?
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.
We set rescoredDocIds in the query phase and use them in the explain of the fetch phase. If we pass the rescoredDocIds around, then we can remove this.
@jimczi Thank you for your review :). |
With this change, we partially move the state of SearchContext to ReaderContext. This is another step allowing us to move the state of search to the coordinating node. We will need several follow-ups to move the entire search state to the coordinating node. Relates #46523
Previously, we resolve IndexService and IndexShard once when creating a search context. However, since #51282, we resolve them in every phase as we recreate a search context in each phase. This change can cause the dfs_query or fetch phase to fail with ShardNotFoundException while previously did not. This behavior is quite subtle, but I think we should make it in line with the master branch.
With this change, we partially move the state of SearchContext to ReaderContext. This is another step allowing us to move the state of search to the coordinating node.
We will need several follow-ups to move the entire search state to the coordinating node.
Relates #46523
Note: this pull request targets the
reader-context
branch.