## Problem Today we use a single index for all data types. There are many problems with this described in https://gitlab.com/gitlab-org/gitlab/-/issues/3217 but a major motivating factor for moving to indices for each data type is performance. Issues and Notes have already been moved and seen improvements in response times. We think that total response time for merge request searches can be reduced if those merge requests are in a dedicated index rather than the combined index with all the other data types. ## Solution Move all merge request documents to a dedicated index. This will have several challenges that we need to overcome and may require several MRs to accomplish. ## Proposal (issues will be opened for each) 1. Denormalise the merge request permission data. This may be done over a few MRs which should be completed in order: 1. Change project and group-wide searches to use the existing `target_project_id` field already on the merge requests. 1. Add `visibility_level` and `merge_requests_visibility_level` to the merge request documents when they are indexed. Trigger updates to all associated merge requests whenever the project permissions change. This work must be done in the same MR to avoid project permissions getting out of sync. 1. Create an ES migration to update all the existing merge request documents with the project permissions fields. 1. Change global searches to use the new denormalised fields rather than the join to parent 1. Move all of the merge requests: add a migration that pauses indexing, moves the merge requests over to the new index, ensures reads and writes for merge requests are now coming from the new index and then deletes the merge requests from the existing index. This may be done over a few MRs, but they **must be merged together**. \*\* Use this issue for the primary document move MR https://gitlab.com/gitlab-org/gitlab/-/issues/322800 \*\*