3 ms·
Transactions are only necessary when the change is tightly coupled. --- In this case, it's okay for individual records to fail. They can either be manually pr
by SkyPuncher 4y ago
Transactions are only necessary when the change is tightly coupled.
---
In this case, it's okay for individual records to fail. They can either be manually processed, re-run, or root caused for failure and handled individually.
- swe_dima 4y agoGroupping several updates inside a transaction actually makes it faster because database doesn't have to "commit" changes for each one. This has diminishing returns however, if too much data changes inside a transaction it can becomes slower due to memory issues. So something like 1000-10000 updates per transaction is a sweet spot I think.
- what-no-tests 4y agoTHIS. A lot of the work I do involves analyzing and improving Ruby applications' performance. Often, simply wrapping transactions around the database operations will help - without making other (often much needed) structural changes.
- SkyPuncher 4y agoWhile you're technically correct, it's probably unlikely performance is going to matter for these types of mass updates. As long as performance isn't atrocious, theres one-time updates will be "fast enough". Typically, these get run during off-peak hours. This running in 30 minutes vs 12 hours simply isn't important.