count optimization for multisplits #5048
Merged
Conversation
This file contains 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
fulmicoton
reviewed
May 30, 2024
| .map_err(|err| SearchError::InvalidQuery(err.to_string()))?; | ||
|
|
||
| // CanSplitDoBetter or rewrite_request may have changed the request to be a count only request | ||
| // This may be the case for AllQuery with a sort by date, where the current split can't have |
fulmicoton
reviewed
May 30, 2024
| /// This is done by exclusion, so we will need to keep it up to date if fields are added. | ||
| /// | ||
| /// The passed query_ast should match the serialized on in request. | ||
| pub fn is_metadata_count_request_with_ast(query_ast: &QueryAst, request: &SearchRequest) -> bool { |
There was a problem hiding this comment.
Suggested change
| pub fn is_metadata_count_request_with_ast(query_ast: &QueryAst, request: &SearchRequest) -> bool { | |
| fn is_metadata_count_request_with_ast(query_ast: &QueryAst, request: &SearchRequest) -> bool { |
There was a problem hiding this comment.
this is also used in leaf.rs
trinity-1686a
approved these changes
May 30, 2024
* optimization requests by passing threshold in leaf search * Execute query.count() instead of QuickwitCollector for count searches We have 100 concurrent split searches by default, but num_cpus worker threads. This means most search futures will wait to be scheduled. When they are scheduled they can check the new threshold from the preceding searches and maybe skip the search. Switches to RWLock for the threshold since we read more often now. Future Work: We run num_cpu full searches in some cases before the threshold kicks in. But in some cases we could statically analyze from which split the best results come and generate count only requests for the others. Addresses #5032
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
We have 100 concurrent split searches by default, but num_cpus worker
threads. This means most search futures will wait to be
scheduled. When they are scheduled they can check the new threshold from
the preceding searches and maybe skip the search.
Switches from Mutex to RWLock for the threshold since we read more often now.
Addresses #5032
Local SSD:
https://qw-benchmarks.104.155.161.122.nip.io/?run_ids=1707,1708&search_metric=engine_duration
CI on S3:
https://qw-benchmarks.104.155.161.122.nip.io/?run_ids=1694,1710&search_metric=engine_duration
Future Work
We run num_cpu full searches in some cases before the threshold kicks
in. But in some cases we could statically
analyze from which split the best results come and generate count only
requests for the others. For that we need the counts, so either we send them to the leaf or this optimization happens on the root.
We can pass a threshold based on the limits of the fast field (if available) for numeric queries