Hacker News Reader

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.

View on HN

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.

While 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.

THIS.

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.

Reply on news.ycombinator.com