1. 08 Apr, 2019 1 commit
  2. 04 Apr, 2019 2 commits
    • Igor's avatar
      Consider array params on rendering MR list on dashboard · 5b6db251
      Igor authored
      This fixes the bug, when approver filter is provided,
      but dashboard asks to enter any filter
      5b6db251
    • Sean McGivern's avatar
      Extend CTE search optimisation to projects · 10ceb33b
      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.
      10ceb33b
  3. 19 Mar, 2019 1 commit
  4. 28 Feb, 2019 1 commit
    • Mario de la Ossa's avatar
      Always use CTE for IssuableFinder counts · 39afba06
      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.
      39afba06
  5. 21 Feb, 2019 1 commit
  6. 06 Feb, 2019 1 commit
  7. 05 Feb, 2019 1 commit
  8. 14 Jan, 2019 1 commit
  9. 31 Dec, 2018 2 commits
  10. 07 Dec, 2018 1 commit
  11. 06 Dec, 2018 1 commit
  12. 30 Nov, 2018 1 commit
    • Sean McGivern's avatar
      Add a flag to use a subquery for group issues search · 7fd5dbf9
      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.
      7fd5dbf9
  13. 23 Nov, 2018 1 commit
    • jacopo's avatar
      Filter by `None`/`Any` for labels in issues/mrs API · c068ac67
      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
      c068ac67
  14. 14 Nov, 2018 1 commit
  15. 01 Nov, 2018 1 commit
  16. 31 Oct, 2018 4 commits
  17. 26 Oct, 2018 2 commits
  18. 18 Oct, 2018 1 commit
  19. 05 Oct, 2018 1 commit
  20. 03 Oct, 2018 1 commit
  21. 01 Oct, 2018 2 commits
  22. 11 Sep, 2018 2 commits
  23. 30 Jul, 2018 1 commit
  24. 28 Jun, 2018 1 commit
  25. 07 Jun, 2018 1 commit
    • Sean McGivern's avatar
      Force Postgres to avoid trigram indexes when in a group · c03386c3
      Sean McGivern authored
      When filtering issues with a search string in a group, we observed on GitLab.com
      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.
      c03386c3
  26. 06 Jun, 2018 1 commit
    • Sean McGivern's avatar
      Simplify issuable finder queries · 57e6a98c
      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.
      57e6a98c
  27. 21 May, 2018 1 commit
  28. 09 Apr, 2018 1 commit
  29. 04 Apr, 2018 1 commit
  30. 05 Mar, 2018 1 commit
  31. 22 Feb, 2018 1 commit
  32. 21 Feb, 2018 1 commit
    • Sean McGivern's avatar
      Refactor IssuableFinder to extract model-specific logic · c2fc4066
      Sean McGivern authored
      By extracting a new `filter_items` method, we can override that in the
      IssuesFinder and MergeRequestsFinder separately, so we don't need checks that
      the model is the correct one, because we can just use the class we're in to know
      that.
      
      We can do the same for the VALID_PARAMS constant, by making it a class method.
      c2fc4066