Reduce N+1 queries when MRs has blocking MRs
What does this MR do and why?
When querying the mergeable
or detailedMergeStatus
GraphQL fields of merge requests and merge requests have blocking MRs, it can result to N+1 SQL queries to check mergeability of MRs based on blocking MRs.
To prevent that, we preload blocking_merge_requests
of merge requests.
N+1 queries I see locally
SELECT "merge_requests".* FROM "merge_requests"... -- (expected: 0, got: 1) INNER JOIN "merge_request_blocks" ON "merge_requests"."id" = "merge_request_blocks"."blocking_merge_request_id" WHERE "merge_request_blocks"."blocked_merge_request_id" = 644 -- (expected: 0, got: 1) INNER JOIN "merge_request_blocks" ON "merge_requests"."id" = "merge_request_blocks"."blocking_merge_request_id" WHERE "merge_request_blocks"."blocked_merge_request_id" = 643 -- (expected: 0, got: 1) INNER JOIN "merge_request_blocks" ON "merge_requests"."id" = "merge_request_blocks"."blocking_merge_request_id" WHERE "merge_request_blocks"."blocked_merge_request_id" = 642Query plan: https://console.postgres.ai/gitlab/gitlab-production-tunnel-pg12/sessions/26375/commands/82766
MR acceptance checklist
Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Related to #441204 (closed)
Edited by Patrick Bajao