-
Notifications
You must be signed in to change notification settings - Fork 114
Attempting to simplify the IO read traits #5935
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: develop
Are you sure you want to change the base?
Conversation
5b2562d to
344b500
Compare
Codecov Report❌ Patch coverage is ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Benchmarks: TPC-H SF=1 on NVMESummary
Detailed Results Table
|
Benchmarks: FineWeb NVMeSummary
Detailed Results Table
|
Benchmarks: TPC-H SF=1 on S3Summary
Detailed Results Table
|
Benchmarks: TPC-DS SF=1 on NVMESummary
Detailed Results Table
|
Benchmarks: TPC-H SF=10 on NVMESummary
Detailed Results Table
|
Benchmarks: FineWeb S3Summary
Detailed Results Table
|
Benchmarks: Statistical and Population GeneticsSummary
Detailed Results Table
|
Benchmarks: TPC-H SF=10 on S3Summary
Detailed Results Table
|
Benchmarks: Clickbench on NVMESummary
Detailed Results Table
|
b53c46e to
a7a3b75
Compare
a7a3b75 to
7400f87
Compare
7400f87 to
a7e2722
Compare
|
|
||
| async move { req.resolve(Compat::new(read).await) } | ||
| }) | ||
| .map(move |f| self2.handle.spawn(f)) |
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 lost, right? I'm not entirely sure why we needed it, but the new drive implementation doesn't spawn the read future, right?
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.
Yeah I'm not convinced its necessary. reqwest already spawns some work, and object_store is tightly coupled with tokio and has its own abstraction (SpawnedReqwestConnector) for spawning work on a dedicated runtime.
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.
👍
danking
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.
Count me in for a single I/O source trait!
danking
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.
They can revoke my approval privileges if they don't like my yolo approvals
|
|
||
| async move { req.resolve(Compat::new(read).await) } | ||
| }) | ||
| .map(move |f| self2.handle.spawn(f)) |
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.
👍
| fn coalesce_config(&self) -> Option<CoalesceConfig> { | ||
| None | ||
| } |
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 am interested why you think we should put this here. I would this the is a property of the underlying file system not the API to read from it. ebs vs local disk would be a good example.
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.
My assumption is that most systems will have their own VortexRead implementation for some adapter type (maybe we should provide some?) or some other custom type, and they can tune it to their expected hardware.
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 see you want this method to be modified by an adapter. I wonder if it makes sense to move from out of the trait and use composition?
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.
More traits really increase the complexity IMO, I would really love to keep this in one trait.
3cf35d9 to
678a26e
Compare
gatesn
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.
Give me some time to grok this..
8b74a6b to
f14e9fa
Compare
|
After talking to @gatesn offline, I moved a lot of the file-specific logic from |
93b23ab to
0449c0e
Compare
Signed-off-by: Adam Gutglick <[email protected]>
Signed-off-by: Adam Gutglick <[email protected]>
Signed-off-by: Adam Gutglick <[email protected]>
Signed-off-by: Adam Gutglick <[email protected]>
Signed-off-by: Adam Gutglick <[email protected]>
Signed-off-by: Adam Gutglick <[email protected]>
b66d6c7 to
3b9a7ef
Compare
We currently have 3 traits (
IntoReadSource,ReadSourceandVortexReadAt), each implemented for different types, but with a large overlap between them. At least for me, it isn't obvious how to extend it for a custom type or how they are relate to each other.This PR is an attempt at trying to refactor the world of IO traits and types, in order to make it easier for users to provide their own specialized IO objects for observability/caching or any other reason.
I've tried to reduce the number of things a user needs to care and know about, ideally leaving us with a smaller API surface.