Bug 1297612

Summary: [SLOW QUERY] tasks to run for a certain package
Product: [Retired] Beaker Reporter: Dan Callaghan <dcallagh>
Component: schedulerAssignee: beaker-dev-list
Status: CLOSED DEFERRED QA Contact: tools-bugs <tools-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 21CC: mjia, tklohna
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-04-15 12:37:21 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Dan Callaghan 2016-01-12 02:31:03 UTC
Shows up with high frequency in the slow query log, presumably this is from tasks.filter being called with a 'package' filter by workflow commands and/or other automation when generating jobs.

Count: 118347  Time=0.09s (10277s)  Lock=0.00s (13s)  Rows_sent=10.0 (1182100), Rows_examined=19786.7 (2341698057), beaker[beaker]@localhost
  SELECT task.id AS task_id, task.name AS task_name, task.rpm AS task_rpm, task.path AS task_path, task.description AS task_description, task.repo AS task_repo, task.avg_time AS task_avg_time, task.destructive AS task_destructive, task.nda AS task_nda, task.creation_date AS task_creation_date, task.update_date AS task_update_date, task.uploader_id AS task_uploader_id, task.owner AS task_owner, task.version AS task_version, task.license AS task_license, task.priority AS task_priority, task.valid AS task_valid 
  FROM task 
  WHERE task.valid = true AND (EXISTS (SELECT N 
  FROM task_packages_runfor_map, task_package 
  WHERE task.id = task_packages_runfor_map.task_id AND task_package.id = task_packages_runfor_map.package_id AND task_package.package = 'S'))

Add index on task.valid, I think that will keep it from being logged with log_queries_not_using_indexes=1. I don't think there is anything else we can optimize in this one.

Comment 1 Tomas Klohna 🔧 2019-04-15 12:37:21 UTC
We know that the database is generally slow, having a ticket for each slow part of the database is not really useful. We will fix it together with other DB issues.