Skip to content

Remove what complexity we can from group issues search

The story so far:

  1. We were suffering from timeouts on GitLab.com when using a search param on the group issues list: https://gitlab.com/gitlab-org/gitlab-ce/issues/46648
    1. We solved this with a fairly ugly change. We used a CTE as an optimisation fence so that Postgres would pick the 'correct' index for this query: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/19429
  2. This broke sorting by popularity, priority, and label priority: https://gitlab.com/gitlab-org/gitlab-ce/issues/50246
    1. We tried to resolve this by removing the CTE: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21521
    2. However, we saw performance issues return: https://gitlab.com/gitlab-org/gitlab-ce/issues/52271#note_109523119
  3. Now we have added a subquery: https://gitlab.com/gitlab-org/gitlab-ce/issues/52271#note_120061396

What we'd like to do in this issue is:

  1. Ensure that we're not using the CTE in production.
  2. Remove the code relating to it (use_cte_for_group_issues_search is the string to grep for).