Follow-up from https://gitlab.com/gitlab-org/gitlab/merge_requests/18277#note_227990430 For the `keys.type` column, we have the following distribution on GitLab.com: ```sql gitlabhq_production=# select type, count(*) from keys group by 1; type | count -----------+--------- | 2385078 DeployKey | 256421 (2 rows) ``` `User.regular_keys` performs a filter on `type = 'Key' or type IS NULL`. The `OR` may become a problem for performance, unless there are other narrow filters applied. It might make sense to migrate `NULL` values to a proper `type` value. * https://gitlab.com/gitlab-org/gitlab/blob/master/app/models/key.rb#L38 * https://gitlab.com/gitlab-org/gitlab/blob/master/ee%2Fapp%2Fmodels%2Fee%2Fkey.rb#L15 Similarly, we have `User.find_by_ssh_key` which in reality doesn't care about the `type` of a key. The method should get renamed to avoid confusion. While we're at this, it may be worth considering to transition to an `integer` enum column instead of storing strings for `type`. ### Proposal (by @vyaklushin) The issue description is old. Nowadays, we have `DeployKey`, `LDAPKey` and `GroupDeployKey` types. 1. Before doing that we should double check if all NULL type records can be marked as `Key`. 2. If all good, update Rails to set `Key` type for new normal key records 2. Create a migration to assign `Key` type of all NULL type records. 3. Make the `type` field NOT NULL 4. Remove `OR type IS NULL` from Rails queries ([for example here](https://gitlab.com/gitlab-org/gitlab/blob/2b6581c7cecbe736443d24c159a0576ea078a010/app/models/key.rb#L64) and in other places)