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:
parent
fb18c43de9
commit
70599a545c
|
@ -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
|
||||
|
||||
|
|
Loading…
Reference in New Issue