## Summary The `taggings` is one of the top 10 most large tables in the CI database. In it's current form we can't partition it using the regular workflow because it is a polymorphic table with ties to `p_ci_builds` and `ci_runners`. A different problem that comes out of this is that we don't have foreign keys to remove the data from this table once a job or runner is deleted, so we have a lot of orphan rows in there. This table is created by the `acts-as-taggable-on` gem to store the links between the `tags` and our tables. ## Improvement steps - vendor in `acts-as-taggable-on` gem - keep only the features that we use from `acts-as-taggable-on` - create two separate tables for converting the polymorphic relations to regular relations. `p_ci_builds_tags`(partitioned) and `ci_runners_tags`. - modify the application to write to the new tables when records are inserted into `taggings` with a FF guard, similar to how [metadatable](https://gitlab.com/gitlab-org/gitlab/-/blob/ebf1aa86b28adf1b91497a41f1ef3d9d8d4f36f7/app/models/concerns/ci/metadatable.rb#L60-117) works. - modify the application to read from the new tables with fallback on the `taggings` table when the data is empty - backfill the new tables with data from `taggings` - cleanup and drop the `taggings` table Note: Ensure the new tables have appropriate sharding keys for cells ## Risks - break job queuing - slow pipeline creation ## Involved components ## Optional: Intended side effects ## Optional: Missing test coverage