N+1 queries in NotificationRecipientService
From https://gitlab.com/gitlab-org/gitlab-ce/issues/45526, we see that NotificationRecipientService
has a number of N+1 queries, particularly when retrieving notification settings from each participant:
QueryRecorder
reveals this with this spec:
require 'spec_helper'
describe NotificationRecipientService do
let(:service) { described_class }
let(:assignee) { create(:user) }
let(:project) { create(:project, :private) }
describe '#build_new_note_recipients' do
let(:issue) { create(:issue, project: project, assignees: [assignee]) }
let(:note) { create(:note_on_issue, noteable: issue, project_id: issue.project_id) }
def create_participant
participant = create(:user)
project.add_master(participant)
issue.subscriptions.create(user: participant, project: project, subscribed: true)
end
it 'avoids N+1 queries' do
create_participant
service.build_new_note_recipients(note)
control_count = ActiveRecord::QueryRecorder.new do
service.build_new_note_recipients(note)
end
create_participant
expect { service.build_new_note_recipients(note) }.not_to exceed_query_limit(control_count)
end
end
end
Results:
1) NotificationRecipientService#build_new_note_recipients avoids N+1 queries
Failure/Error: expect { service.build_new_note_recipients(note) }.not_to exceed_query_limit(control_count)
Expected a maximum of 18 queries, got 23:
Extra queries:
[2] SELECT "notification_settings"."user_id" FROM "notification_settings" WHERE "notification_settings"."level" = $1 AND "notification_settings"."user_id" IN (5, 1, 2) AND "notification_settings"."source_type" IS NULL
[1] SELECT "users".* FROM "users" WHERE "users"."id" = $1 LIMIT 1
[1] SELECT "notification_settings".* FROM "notification_settings" WHERE "notification_settings"."user_id" IN (1, 5)
[2] SELECT 1 AS one FROM "users" INNER JOIN "project_authorizations" ON "users"."id" = "project_authorizations"."user_id" WHERE "project_authorizations"."project_id" = $1 AND "users"."id" = $2 LIMIT 1
[1] SELECT 1 AS one FROM "users" INNER JOIN "issue_assignees" ON "users"."id" = "issue_assignees"."user_id" WHERE "issue_assignees"."issue_id" = $1 AND "users"."id" = $2 LIMIT 1
[1] SELECT "subscriptions".* FROM "subscriptions" WHERE "subscriptions"."subscribable_id" = $1 AND "subscriptions"."subscribable_type" = $2 AND "subscriptions"."user_id" = $3 LIMIT 1
The issue here is that Participable#raw_participants
builds a set of users and doesn't provide a way to preload attributes.