Read about our upcoming Code of Conduct on this issue

This instance will be upgraded to Heptapod 0.28.1 on 2022-01-26 at 16:00 UTC+1 (a few minutes of down time)

  1. 07 May, 2019 1 commit
  2. 09 Apr, 2019 1 commit
  3. 08 Apr, 2019 1 commit
  4. 05 Apr, 2019 2 commits
  5. 04 Apr, 2019 1 commit
    • Sean McGivern's avatar
      Extend CTE search optimisation to projects · 6a5ac2ef25dd
      Sean McGivern authored
      When we use the `search` param on an `IssuableFinder`, we can run into
      issues. We have trigram indexes to support these searches. On
      GitLab.com, we often see Postgres's optimiser prioritise the (global)
      trigram indexes over the index on `project_id`. For group and project
      searches, we know that it will be quicker to filter by `project_id`
      first, as it returns fewer rows in most cases.
      
      For group issues search, we ran into this issue previously, and went
      through the following iterations:
      
      1. Use a CTE on the project IDs as an optimisation fence. This prevents
         the planner from disregarding the index on `project_id`.
         Unfortunately it breaks some types of sorting, like priority and
         popularity, as they sort on a joined table.
      2. Use a subquery for listing issues, and a CTE for counts. The subquery
         - in the case of group lists - didn't help as much as the CTE, but
         was faster than not including it. We can safely use a CTE for counts
         as they don't have sorting.
      
      Now, however, we're seeing the same issue in a project context. The
      subquery doesn't help at all there (it would only return one row, after
      all). In an attempt to keep total code complexity under control, this
      commit removes the subquery optimisation and applies the CTE
      optimisation only for sorts we know that are safe.
      
      This means that for more complicated sorts (like priority and
      popularity), the search will continue to be very slow. If this is a
      high-priority issue, we can consider introducing further optimisations,
      but this finder is already very complicated and additional complexity
      has a cost.
      
      The group CTE optimisation is controlled by the same feature flag as
      before, `attempt_group_search_optimizations`, which is enabled by
      default. The new project CTE optimisation is controlled by a new feature
      flag, `attempt_project_search_optimizations`, which is disabled by
      default.
      6a5ac2ef25dd
  6. 21 Mar, 2019 1 commit
  7. 19 Mar, 2019 1 commit
  8. 28 Feb, 2019 1 commit
    • Mario de la Ossa's avatar
      Always use CTE for IssuableFinder counts · 82066cd4c80d
      Mario de la Ossa authored
      Since the CTE is faster than a subquery and the only reason we're using
      a subquery is that the CTE can't handle sorting by certain attributes,
      let's use the CTE always (when the feature flag is enabled) when
      counting, since we can ignore ordering if we just want a count of
      results.
      82066cd4c80d
  9. 26 Feb, 2019 1 commit
  10. 25 Feb, 2019 1 commit
  11. 22 Feb, 2019 1 commit
  12. 21 Feb, 2019 2 commits
  13. 14 Jan, 2019 1 commit
  14. 31 Dec, 2018 1 commit
  15. 30 Nov, 2018 1 commit
    • Sean McGivern's avatar
      Add a flag to use a subquery for group issues search · 0aee72a79c49
      Sean McGivern authored
      We already had a flag to use a CTE, but this broke searching in some
      cases where we need to sort by a joined table. Disabling the CTE flag
      makes searches much slower.
      
      The new flag, to use a subquery, makes them slightly slower than the
      CTE, while maintaining correctness. If both it and the CTE flag are
      enabled, the subquery takes precedence.
      0aee72a79c49
  16. 23 Nov, 2018 1 commit
    • Jacopo's avatar
      Filter by `None`/`Any` for labels in issues/mrs API · 90334172e369
      Jacopo authored
      By using the parameters `?labels=None|Any` the user can filter
      issues/mrs from the API that has `none/any` label.
      
      Affected endpoints are:
      
      - /api/issues
      - /api/projects/:id/issues
      - /api/groups/:id/issues
      - /api/merge_requests
      - /api/projects/:id/merge_requests
      - /api/groups/:id/merge_requests
      90334172e369
  17. 31 Oct, 2018 2 commits
  18. 26 Oct, 2018 2 commits
  19. 03 Oct, 2018 1 commit
  20. 01 Oct, 2018 1 commit
  21. 11 Jul, 2018 1 commit
  22. 21 May, 2018 1 commit
  23. 05 Mar, 2018 1 commit
  24. 01 Feb, 2018 1 commit
  25. 22 Dec, 2017 1 commit
  26. 05 Sep, 2017 1 commit
    • Yorick Peterse's avatar
      Re-use issue/MR counts for the pagination system · 518ba0ce3153
      Yorick Peterse authored
      This changes the issue and MR index pages so the pagination system
      re-uses the output of the COUNT(*) query used to calculate the number of
      rows per state (opened, closed, etc). This removes the need for an
      additional COUNT(*) on both pages.
      518ba0ce3153
  27. 30 Aug, 2017 1 commit
  28. 02 Aug, 2017 1 commit
  29. 07 Jul, 2017 1 commit
  30. 30 Jun, 2017 2 commits
    • Sean McGivern's avatar
      Make finders responsible for counter cache keys · afa11fc7a8f1
      Sean McGivern authored
      afa11fc7a8f1
    • Sean McGivern's avatar
      Only do complicated confidentiality checks when necessary · 89d995b7b60b
      Sean McGivern authored
      When we are filtering by a single project, and the current user has access to
      see confidential issues on that project, we don't need to filter by
      confidentiality at all - just as if the user were an admin.
      
      The filter by confidentiality often picks a non-optimal query plan: for
      instance, AND-ing the results of all issues in the project (a relatively small
      set), and all issues in the states requested (a huge set), rather than just
      starting small and winnowing further.
      89d995b7b60b
  31. 18 Jun, 2017 1 commit
  32. 14 Jun, 2017 1 commit
  33. 05 May, 2017 1 commit
  34. 04 May, 2017 1 commit
  35. 01 May, 2017 1 commit