Query timeout on issues dashboard
### Summary Requests for the issues dashboard (/dashboard/issues) often result in a 500 response due to "PG::QueryCanceled: ERROR: canceling statement due to statement timeout". It seems that the query params make a difference, but many combinations of query params cause statement timeout. For example, see these Sentry reports: - [assignee_username is empty string](https://sentry.gitlab.net/gitlab/gitlabcom/issues/1279879) - [search is "my-reaction:"](https://sentry.gitlab.net/gitlab/gitlabcom/issues/1278471) - [search is "cesionario:=@pcartes"](https://sentry.gitlab.net/gitlab/gitlabcom/issues/1283873) - [and more](https://sentry.gitlab.net/gitlab/gitlabcom/?query=is%3Aunresolved+url%3Ahttps%3A%2F%2Fgitlab.com%2Fdashboard%2Fissues) ### Steps to reproduce 1. Visit https://gitlab.com/dashboard/issues?scope=all&utf8=%E2%9C%93&state=opened&search=%5BInstance+Activity%5D+Store+and+read+data+for 1. Encounter a 500 error ### What is the current *bug* behavior? Ordinary search behavior results in a 500 response. ### What is the expected *correct* behavior? Ordinary search behavior does not result in a 500 response. ### Relevant logs and/or screenshots This problem was noticed after @aakriti.gupta posted [a link to "getting the top containers"](https://gitlab.com/dashboard/issues?scope=all&utf8=%E2%9C%93&state=opened&assignee_username=aakriti.gupta&search=%5BInstance+Activity%5D+Store+and+read+data+for) [in an issue comment](https://gitlab.com/gitlab-org/gitlab/issues/193435#note_287818878). That link results in a [500 error "due to statement timeout"](https://sentry.gitlab.net/gitlab/gitlabcom/issues/1279942/?query=is:unresolved%20url:https://gitlab.com/dashboard/issues). The 500 responses occur even after removing the `assignee_username` param, removing some of the terms from the `search` param, or [removing the `search` param in favor of other params](https://sentry.gitlab.net/gitlab/gitlabcom/issues/1278471/?query=is:unresolved%20url:https://gitlab.com/dashboard/issues). ### Output of checks This bug happens on GitLab.com ### Possible fixes - Improve query performance - Split query into separate queries
issue