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.
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.