Skip to content

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" = 642

Query 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

Merge request reports