-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
[ENH]: parallelize applying materialized log to segment writers #3359
Conversation
Reviewer ChecklistPlease leverage this checklist to ensure your code review is thorough before approving Testing, Bugs, Errors, Logs, Documentation
System Compatibility
Quality
|
This stack of pull requests is managed by Graphite. Learn more about stacking. |
@@ -280,7 +280,7 @@ impl CompactOrchestrator { | |||
None => return, | |||
}; | |||
|
|||
self.num_write_tasks = partitions.len() as i32; | |||
self.num_write_tasks = partitions.len() as i32 * 3; |
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.
this is removed in the next PR in this stack
&self, | ||
record_segment_reader: &Option<RecordSegmentReader>, | ||
materialized_chunk: &MaterializeLogsResult, | ||
) -> Result<(), ApplyMaterializedLogError>; | ||
) -> impl Future<Output = Result<(), ApplyMaterializedLogError>> + Send; |
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.
Interesting, the impl can still be async fn apply_materialized_log_chunk
and this works? Is this because async is just syntactic sugar for that?
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.
yep
b25da8b
to
88c8462
Compare
2e9a2e0
to
d09d690
Compare
d09d690
to
23ef45e
Compare
Description of changes
Applies log updates to segment types in parallel rather than sequentially:
Pipelining flushes to S3/applying to blockfile will be in the next PR in this stack.
Test plan
How are these changes tested?
pytest
for python,yarn test
for js,cargo test
for rustAlso tested with SciDocs.
Documentation Changes
Are all docstrings for user-facing APIs updated if required? Do we need to make documentation changes in the docs repository?
n/a