-
Notifications
You must be signed in to change notification settings - Fork 645
Extract crate_downloads
table
#8232
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
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #8232 +/- ##
=======================================
Coverage 87.72% 87.73%
=======================================
Files 272 272
Lines 27317 27345 +28
=======================================
+ Hits 23965 23992 +27
- Misses 3352 3353 +1 ☔ 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.
Should we expand the test data for crates and their versions to ensure we are updating the correct one?
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 guess that would generally make sense. Since that was already a problem with the existing code I don't want to conflate that with the purpose of this PR though :)
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.
LGTM! My comments are only suggestions, not blockers.
…wnloads` table too This is not removing the `crates` table update just yet, since we need to keep both tables in sync for now until the rest of the code is migrated to reading from the `crate_downloads` table instead.
95e6863
to
fdf1407
Compare
This PR is the first in a sequence of multiple PRs that move the
crates.downloads
column to a dedicated database table.Whenever we update the
crates.downloads
column a full new row is written by Postgres, which causes a lot of churn for the columns in this table that don't actually change that much. We've been seeing quite a few performance issues lately that are supposedly (partially) caused by this behavior.This PR adds a database migration which creates a new
crate_downloads
table, with a commented out query in the migration script to fill the table with the current values. The migration also adds an insert trigger on thecrates
table to ensure a correspondingcrate_downloads
row is automatically created for all newly inserted crates. Deletion of crates is automatically handled byon delete cascade
.The PR also adjusts the
update_downloads
background job to update bothcrates.downloads
andcrate_downloads.downloads
for now. We can remove thecrates.downloads
updates once we switch the backend endpoint to read from thecrate_downloads
table instead.