Read about our upcoming Code of Conduct on this issue

  1. 07 May, 2019 1 commit
  2. 23 Apr, 2019 1 commit
  3. 08 Apr, 2019 1 commit
  4. 04 Apr, 2019 2 commits
    • Igor's avatar
      Consider array params on rendering MR list on dashboard · e59be4992dad
      Igor authored
      This fixes the bug, when approver filter is provided,
      but dashboard asks to enter any filter
    • 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, 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
  5. 19 Mar, 2019 1 commit
  6. 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
  7. 21 Feb, 2019 1 commit
  8. 06 Feb, 2019 1 commit
  9. 05 Feb, 2019 1 commit
  10. 14 Jan, 2019 1 commit
  11. 31 Dec, 2018 2 commits
  12. 07 Dec, 2018 1 commit
  13. 06 Dec, 2018 1 commit
  14. 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.
  15. 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
  16. 14 Nov, 2018 1 commit
  17. 01 Nov, 2018 1 commit
  18. 31 Oct, 2018 4 commits
  19. 26 Oct, 2018 2 commits
  20. 18 Oct, 2018 1 commit
  21. 05 Oct, 2018 1 commit
  22. 03 Oct, 2018 1 commit
  23. 01 Oct, 2018 2 commits
  24. 11 Sep, 2018 2 commits
  25. 30 Jul, 2018 1 commit
  26. 28 Jun, 2018 1 commit
  27. 07 Jun, 2018 1 commit
    • Sean McGivern's avatar
      Force Postgres to avoid trigram indexes when in a group · 662bcc085924
      Sean McGivern authored
      When filtering issues with a search string in a group, we observed on
      that Postgres was using an inefficient query plan, preferring the (global)
      trigram indexes on description and title, rather than using a filter on the
      restricted set of issues within the group.
      Change the callers of the IssuableFinder to use a CTE in this case to fence the
      rest of the query from the LIKE filters, so that the optimiser is forced to
      perform the filter in the order we prefer.
      This will only force the use of a CTE when:
      1. The use_cte_for_search params is truthy.
      2. We are using Postgres.
      3. We have passed the `search` param.
      The third item is important - searching issues using the search box does not use
      the finder in this way, but contructs a query and appends `full_search` to
      that. For some reason, this query does not suffer from the same issue.
      Currenly, we only pass this param when filtering issuables (issues or MRs) in a
      group context.
  28. 06 Jun, 2018 1 commit
    • Sean McGivern's avatar
      Simplify issuable finder queries · 88ec34f46eb6
      Sean McGivern authored
      We had `item_project_ids` to help make slow queries on the dashboard faster, but
      this isn't necessary any more - the queries are plenty fast, and we forbid
      searching the dashboard without filters.
  29. 21 May, 2018 1 commit
  30. 09 Apr, 2018 1 commit
    • Andreas Brandl's avatar
      Reduce complexity of issuable finder query. · 0618f08e6233
      Andreas Brandl authored
      This removes the extra check for project-ids which is not needed at all.
      This does not necessarily reduce execution time of the query, but
      improves planning time by a few millseconds.
      Closes #37125.
  31. 04 Apr, 2018 1 commit
  32. 05 Mar, 2018 1 commit