3 ms·
Groupping several updates inside a transaction actually makes it faster because database doesn't have to "commit" changes for each one. This has diminishing ret
by swe_dima 3y ago
Groupping 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 3y 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 3y 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.