-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Optimize DB calls for list endpoints #9851
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
|
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## develop #9851 +/- ##
===========================================
+ Coverage 73.39% 75.42% +2.02%
===========================================
Files 410 411 +1
Lines 45663 45721 +58
Branches 4086 4086
===========================================
+ Hits 33516 34485 +969
+ Misses 12147 11236 -911
🚀 New features to boost your workflow:
|
|



Motivation and context
GET /api/tasksandGET /api/jobsrequestsCurrent requests to list endpoints consist of 2 DB queries:
COUNTand page objects. TheCOUNTquery uses the same subquery that's used for page objects.Problems:
COUNT DISTINCT, the DB does this over all the columns (including fromselect_related()). This results in degraded performance for no actual reason, because we actually need theCOUNTof unique ids.ORclauses in theWHEREclause. This prevents Postgres from using column indices in these requests, despite having them available.COUNTqueries use some other clauses that prevent it from using indices as well (e.g.ORDER BY,COUNT <columns>), while they do not affect the result.How has this been tested?
Manual testing on a large synthetic DB.
Checklist
developbranchLicense
Feel free to contact the maintainers if that's a concern.