Mediawiki history has long contained three high-level types of actions, split out based on the event_entity field: revision, page, and user. The columns then in the table are largely either filled in or null depending on which event entity the row pertains to. I presume that the majority of rows and queries relate to the revision fields only. This causes a few issues:

• It presumably introduces some overhead on the execution side to skip over the non-relevant rows in a given query.
• It introduces complexity on the end-user side to go through 70+ field schema to find the right ones (including some with similar names but different scopes -- e.g., user_groups_historical vs. event_user_groups_historical).
• Until tasks like T433511: [Mediawiki History] make array fields empty as opposed to null when relevant but no values present, T433517: [Mediawiki History] Default boolean fields to False instead of NULL where relevant, and T433620: [Mediawiki History] Fix missing event_user_is_created_by values are fixed, null values can have multiple meanings (not relevant to the row or missing data or a bug). Ideally we can get to a place where there are no null values (or they're only null when there's a bug, which is a useful signal for prioritizing things to investigate).

I don't know of any analysis that combines the different event_type fields, so I think per above it would be much cleaner to separate them, which would greatly simplify the table schemas and hopefully reduce query time as well. In cases where folks want to combine, they could just union back together as needed. I assume the decision to originally merge them all together made sense 10 years ago, but I'm not sure it will continue to make sense as we iterate and the data grows. So:

• mediawiki_page_history (which we already have) to capture all the page moves, deletions, restores, etc.
• mediawiki_user_history (which we already have) to capture all the changes to users – e.g., renames, group changes, blocks, etc.
• mediawiki_revision_history to capture all revisions (and I guess we could one day include deletion/restore events too or even reverts?)