-
Notifications
You must be signed in to change notification settings - Fork 1.8k
[query api] don't propagate offset into prefetches #6357
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
Conversation
📝 WalkthroughWalkthroughThe changes update the query handling and memory management modules. In the query processing logic, the adjustment of the limit by adding the offset has been removed from the main query code when prefetches are involved. A comment now clarifies that the limit should only be increased by the offset in specific cases without prefetches. Additionally, the recursive prefetch function has been modified by removing the redundant parameter used to pass offset adjustments, simplifying its signature and internal logic. In the memory management module, an unused import for handling file-related operations has been removed and re-scoped to be used only within the 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms (13)
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
@@ -1,7 +1,6 @@ | |||
//! Platform-independent abstractions over [`memmap2::Mmap::advise`]/[`memmap2::MmapMut::advise`] | |||
//! and [`memmap2::Advice`]. | |||
|
|||
use std::fs::File; |
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.
maybe unnecessary on Mac but breaks the build for everyone else :)
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.
It was indeed 'unused' on macOS because it's only usage is gated in
#[cfg(any(
target_os = "linux",
target_os = "freebsd",
target_os = "android",
target_os = "fuchsia",
target_os = "emscripten",
target_os = "wasi",
target_env = "uclibc",
))]
I've moved the import into that scope to resolve the problem.
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.
Could you add a test that asserts this behavior?
Prefetch with and without an offset, and assert that we eventually run out of results. That'll ensure the behavior we document actually happens in practice.
This may break the local mode congruence tests 🔮 |
* don't propagate offset into prefetches * I want to see CI with that change * Move import into platform specific scope * edit test to make sure offset is not propagated * fix planned query test --------- Co-authored-by: Arnaud Gourlay <arnaud.gourlay@gmail.com> Co-authored-by: timvisee <tim@visee.me>
One overlooked quirk when developing prefetches is that we should not propagate the main query offset into them.
In general terms, offsets are not compatible with prefetches. Let's look at one example:
Imagine we have a vector search prefetch (limit=5), and an order_by main query (limit=3). For simplicity, let's assume letters are point IDs, and numbers are the order_by values
As you can see, the second query, with an offset is not consistent with the first one. Result
g
will never appear.With this PR, offset is not propagated anymore, so the limit in the prefetch is the total amount of offsetting that can happen for the request. If the user keeps paginating with offset and a fixed limit, results will be stable, but will eventually lead to an empty result.