-
Notifications
You must be signed in to change notification settings - Fork 6
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
Clean up existing indices on Upload
(aka ReportSession
)
#442
base: main
Are you sure you want to change the base?
Conversation
Looks like the But for that case, I believe having an index would make sense, as otherwise it would do a full table scan there :-D |
04713aa
to
3af2101
Compare
20fc6fa
to
ca4ae14
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #442 +/- ##
==========================================
- Coverage 90.55% 89.97% -0.58%
==========================================
Files 404 324 -80
Lines 12562 9199 -3363
Branches 2107 1633 -474
==========================================
- Hits 11375 8277 -3098
+ Misses 1078 859 -219
+ Partials 109 63 -46
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
ca4ae14
to
5c43c07
Compare
I updated the PR to add a bunch more manually added indices to the cleanup, and after running this, the state of the production DB should be fully aligned with the django migration state. |
5c43c07
to
610dd21
Compare
This in particular cleans up the existing indices that exist in the production DB but not in django: We drop these indices for the following reasons: - `upload_index_id_type_number`: This matches the above state migration, and it looks like the index does not actually exist in the production DB. The following indices exist in the production DB, but not in django state/migrations: - `reports_upload_order_number_idx`: We never query by the `order_number` alone, so this index is likely unused. - `reports_upload_report_id_f6b4ffae`: Queries on `report_id` should already been covered by the newly added index on `report_id`+`upload_type`. - `reports_upload_report_id_upload_type_index_ccnew`: This seems to be a manually added variant of the `upload_report_type_idx` index and is thus duplicated. - `reports_upload_report_id_upload_type_order_number_index`: This is the same as the above, except with an additional `order_number`. We do use it in queries, but I doubt the index pulls its weight, as the `order_number` changes quite frequently so the index is costly to maintain.
610dd21
to
ad1607c
Compare
This in particular cleans up the existing indices that exist in the production DB but not in django:
We drop these indices for the following reasons:
upload_index_id_type_number
: This matches the above state migration,and it looks like the index does not actually exist in the production DB.
The following indices exist in the production DB, but not in django state/migrations:
reports_upload_order_number_idx
:We never query by the
order_number
alone, so this index is likely unused.reports_upload_report_id_f6b4ffae
: Queries onreport_id
should already been covered by thenewly added index on
report_id
+upload_type
.reports_upload_report_id_upload_type_index_ccnew
:This seems to be a manually added variant of the
upload_report_type_idx
index and is thus duplicated.reports_upload_report_id_upload_type_order_number_index
:This is the same as the above, except with an additional
order_number
.We do use it in queries, but I doubt the index pulls its weight, as the
order_number
changes quitefrequently so the index is costly to maintain.