-
Notifications
You must be signed in to change notification settings - Fork 524
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
RFC-3734: Buffered reader #3734
Conversation
bb87a31
to
268b142
Compare
268b142
to
83f10e8
Compare
Another idea came to my mind: we can support multiple buffering policies for different purposes. i.e., only buffer the partial read and prefetched segments for future use(the segment prefetching will be introduced with the concurrent fetching feature). Maybe we should leave it as future work. |
1e4015f
to
2dbced7
Compare
2dbced7
to
13d7cdf
Compare
bf07ef1
to
6400337
Compare
6400337
to
fa960e5
Compare
Sorry for the delay. Please take a look when you have time. Thanks🥹 |
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.
Thanks! Mostly LGTM.
For me, mostly LGTM. BTW, I have a suggestion here, maybe we need to add a Because some of the service like PGSQL,MySQL etc.. are dedicated to the small file. This is probably an implementation issue, I'm not sure we need add extra description in RFC docs |
Users don't care about buffer can just don't use this API. And besides, buffer is useful even when file is small. For example, read(1), seek(1), read(2). |
Make sense. |
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.
LGTM
We got three approvals now, merging! |
cool |
This RFC proposes a buffered reader to amortize the overhead of IO. The concurrent fetching feature will be introduced in another RFC soon.
Related