From f149e514c14f320819ef60ed3902ed36689136fd Mon Sep 17 00:00:00 2001
From: Nick LaMuro <nicklamuro@gmail.com>
Date: Tue, 26 Feb 2019 17:51:26 -0600
Subject: [PATCH] [Performance] Remove compliance from VmOrTemplate includes

Over time, the `compliances` table will get quiet large, and when paired
with the rest of the tables in this report, you end up getting a query
executed that looks like this:

    SELECT "vms"."id" AS t0_r0, ..., "vms"."memory_hot_add_increment" AS t0_r75,
           "hosts"."id" AS t1_r0, ..., "hosts"."physical_server_id" AS t1_r36,
           "storages"."id" AS t2_r0, ..., "storages"."storage_domain_type" AS t2_r18,
           "ext_management_systems"."id" AS t3_r0, ..., "ext_management_systems"."tenant_mapping_enabled" AS t3_r23,
           "snapshots"."id" AS t4_r0, ..., "snapshots"."ems_ref" AS t4_r16,
           "compliances"."id" AS t5_r0, ..., "compliances"."event_type" AS t5_r6,
           "operating_systems"."id" AS t6_r0, ..., "operating_systems"."kernel_version" AS t6_r25,
           "hardwares"."id" AS t7_r0, ..., "hardwares"."provision_state" AS t7_r34,
           "tags"."id" AS t8_r0, "tags"."name" AS t8_r1
    FROM "vms"
    LEFT OUTER JOIN "hosts" ON "hosts"."id" = "vms"."host_id"
    LEFT OUTER JOIN "storages" ON "storages"."id" = "vms"."storage_id"
    LEFT OUTER JOIN "ext_management_systems" ON "ext_management_systems"."id" = "vms"."ems_id"
    LEFT OUTER JOIN "snapshots" ON "snapshots"."vm_or_template_id" = "vms"."id"
    LEFT OUTER JOIN "compliances" ON "compliances"."resource_id" = "vms"."id" AND "compliances"."resource_type" = $1
    LEFT OUTER JOIN "operating_systems" ON "operating_systems"."vm_or_template_id" = "vms"."id"
    LEFT OUTER JOIN "hardwares" ON "hardwares"."vm_or_template_id" = "vms"."id"
    LEFT OUTER JOIN "taggings" ON "taggings"."taggable_id" = "vms"."id" AND "taggings"."taggable_type" = $2
    LEFT OUTER JOIN "tags" ON "tags"."id" = "taggings"."tag_id"
    WHERE "vms"."type" IN (...)
      AND "vms"."template" = $3
      AND (lower(vms.name) like '%win2k%' escape '`')
      AND "vms"."id" IN (...)
    ORDER BY LOWER("vms"."name") ASC

This ends up creating 243 columns per record, and the number of rows
returned has been observed to be over 80k with just 20 VMs being
targeted in the `"vms"."id" IN (...)` portion of the query.

Since some fixes have been made to avoid the N+1 that results from doing
this:

- https://github.com/ManageIQ/manageiq/pull/17473
- https://github.com/ManageIQ/manageiq/pull/17474
- https://github.com/ManageIQ/manageiq/pull/17475

It is much better to do use those facilities.  Even with the N+1, it is
much better making extra round trips than the gigs of data that would be
returned as a result.
---
 product/views/VmOrTemplate.yaml | 1 -
 1 file changed, 1 deletion(-)

diff --git a/product/views/VmOrTemplate.yaml b/product/views/VmOrTemplate.yaml
index 506c43ea601..5ae19fce344 100644
--- a/product/views/VmOrTemplate.yaml
+++ b/product/views/VmOrTemplate.yaml
@@ -44,7 +44,6 @@ include:
 # Included tables and columns for query performance
 include_for_find:
   :snapshots: {}
-  :compliances: {}
   :operating_system: {}
   :hardware: {}
   :tags: {}