The cu_changes table has data copied from the recentchanges table, via a hook, but does not copy the rc_old_len and rc_new_len columns. These aren't that important for the CheckUser, but they are very much a "nice to have" for the Special:RangeContributions tool (T145912), so we can show the diff size for each edit, like you see on all other lists of edits (watchlist, recent changes, Special:Contribs). We could also start showing diff sizes in the CheckUser tool itself, which may be a welcomed change.
Because the data is copied via the RecentChange_save hook, I think if we were to ALTER the table we'd have to first remove the hook or else it would block updates to the recentchanges table.
The questions are:
- Is it even feasible to add the cuc_old_len and cuc_new_len columns to cu_changes given the size of the table (17,705,197 rows on enwiki at the time of writing)?
- Roughly how much time will the migration take?
- Will CheckUser's be OK with the downtime, given the benefit of being able to efficiently show diff sizes moving forward?
- As an alternative, can we compute the diff sizes as needed within the RangeContributions tool without noticeable effect on load time?
- Would we be able to backfill the old data? What about the CU data that wasn't being copied while the migration was taking place?