-
-
Notifications
You must be signed in to change notification settings - Fork 672
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: Transparently fetch multiple documents grouped per block #2276
base: main
Are you sure you want to change the base?
Conversation
9ce44a3
to
d6e1ec8
Compare
d6e1ec8
to
6fe01c4
Compare
6fe01c4
to
59695d1
Compare
&self, | ||
doc_addresses: impl IntoIterator<Item = DocAddress>, | ||
) -> crate::Result< | ||
impl Iterator<Item = impl Future<Output = crate::Result<Vec<(DocAddress, D)>>>> + '_, |
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.
The signature is admittedly somewhat unwieldy even though relatively easy to use in practice as the test shows. I wonder if I should add a no_run
example showing usage with FuturesUnordered
? (no_run
to avoid making the example unreadable due to index setup code. Alternatively the setup code could be hidden.)
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.
Added a no_run
example on how to use this with FuturesUnordered
and block_on
.
d00dd5a
to
a2953d6
Compare
…by group them by segment and block.
…PI if only Searcher::docs_async uses them.
a2953d6
to
d1177fe
Compare
My personal take on the discussion in #2252, i.e. expose enough information and control to schedule concurrent reads into independent block caches as to maximize cache effectiveness and then expose this as
Searcher::docs_async
which yields an iterator of futures which user code can then poll concurrently or in parallel as it sees fit.