use postgres any in duedatecacher quiz lti lookup

Switch to using the postgres any statement instead of the AR generated
IN statement in the ContentTag query in the DueDateCacher. Per our DBAs
it is much faster in the postgres planner. 1.2-2.1 ms down to .7-.9 for
large datasets.

test plan:
 - specs pass

Change-Id: I9fe29806df72fa186490087d32b5d22008a06fc6
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/271236
Reviewed-by: Cody Cutrer <cody@instructure.com>
Reviewed-by: Spencer Olson <solson@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Keith Garner <kgarner@instructure.com>
Product-Review: Keith Garner <kgarner@instructure.com>
This commit is contained in:
Keith T. Garner 2021-08-11 17:05:21 -05:00 committed by Keith Garner
parent fb18c43de9
commit 70599a545c
1 changed files with 5 additions and 1 deletions

View File

@ -365,7 +365,11 @@ class DueDateCacher
@quiz_lti_assignments ||=
ContentTag.joins("INNER JOIN #{ContextExternalTool.quoted_table_name} ON content_tags.content_type='ContextExternalTool' AND context_external_tools.id = content_tags.content_id").
merge(ContextExternalTool.quiz_lti).
where(context_type: 'Assignment', context_id: @assignment_ids).
where(context_type: 'Assignment').#
# We're doing the following direct postgres any() rather than .where(context_id: @assignment_ids) on advice
# from our DBAs that the any is considerably faster in the postgres planner than the "IN ()" statement that
# AR would have generated.
where("content_tags.context_id = any('{?}'::int8[])", @assignment_ids).
where.not(workflow_state: 'deleted').distinct.pluck(:context_id).to_set
end