-
Notifications
You must be signed in to change notification settings - Fork 645
Improve crates endpoint performance #7941
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
Enable consistent filtering for both data retrieval and count queries, and ensure accurate totals in seek-based pagination.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #7941 +/- ##
=======================================
Coverage ? 87.57%
=======================================
Files ? 257
Lines ? 25101
Branches ? 0
=======================================
Hits ? 21982
Misses ? 3119
Partials ? 0 ☔ View full report in Codecov by Sentry. |
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 like this! I particularly like the new test assertions.
I experimented with a similar change last year, but trying to fully automatically build the count query instead of having it added separately. Turned out to be really hard (maybe actually impossible, right now?) because of what Diesel does and doesn't expose from its innards. So I like this as a pragmatic middle ground, and I like that the changes to the controller weren't as bad as I thought they'd be last year.
@Turbo87 Let's give this a quick once over on staging before we deploy, but I think this is good.
} | ||
|
||
fn supports_seek(&self) -> bool { | ||
// Calculating the total number of results with filters is supported but paging is not supported yet. |
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'm correct in thinking this isn't a regression, right, because we don't support this today?
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.
Yes, and I also like to make a follow up PR which expands the scope of the seek-based pagination for crates endpoint.
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.
For offset-based pagination, the response will remain unchanged. The only modification pertains to seek-based pagination. Previously, we provided an approximate total count; however, with this PR, the total count will align precisely with the offset-based count.
I've just deployed thanks a lot for the work, @eth3lbert! :) |
Revert "Merge pull request #7941 from eth3lbert/count-subq"
Cross-referencing here: we had to revert this PR because it broke search queries with spaces in them. New issue for re-landing: #8052 |
Re-introducing improve crates endpoint performance (#7941)
This pr improve the performance by utilizing a count subquery for total retrieval.
P.S. make a separate query to fetch total should also outperforms window functions in this context.