An error occurred fetching the project authors.
  1. 05 Oct, 2018 1 commit
  2. 03 Oct, 2018 1 commit
  3. 01 Oct, 2018 2 commits
  4. 27 Sep, 2018 1 commit
  5. 11 Sep, 2018 3 commits
  6. 30 Jul, 2018 1 commit
  7. 29 Jun, 2018 1 commit
  8. 28 Jun, 2018 1 commit
  9. 07 Jun, 2018 3 commits
    • Sean McGivern's avatar
      Force Postgres to avoid trigram indexes when in a group · 7af70a4e
      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.
      7af70a4e
    • Sean McGivern's avatar
      Simplify issuable finder queries · f70a5258
      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.
      f70a5258
    • 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
  10. 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
  11. 21 May, 2018 2 commits
  12. 09 Apr, 2018 1 commit
    • Andreas Brandl's avatar
      Reduce complexity of issuable finder query. · cdfe437e
      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.
      cdfe437e
  13. 04 Apr, 2018 3 commits
  14. 05 Mar, 2018 1 commit
  15. 23 Feb, 2018 1 commit
  16. 22 Feb, 2018 2 commits
  17. 21 Feb, 2018 2 commits
    • Sean McGivern's avatar
      Refactor IssuableFinder to extract model-specific logic · 3c51ff56
      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.
      3c51ff56
    • 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
  18. 01 Feb, 2018 2 commits
  19. 05 Jan, 2018 1 commit
  20. 13 Nov, 2017 1 commit
  21. 27 Sep, 2017 1 commit
  22. 26 Sep, 2017 3 commits
  23. 18 Sep, 2017 1 commit
  24. 14 Sep, 2017 1 commit
  25. 05 Sep, 2017 1 commit
    • Yorick Peterse's avatar
      Re-use issue/MR counts for the pagination system · 42062a45
      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.
      42062a45
  26. 31 Aug, 2017 2 commits
    • Lin Jen-Shin's avatar
      Resolve conflicts · 297b424f
      Lin Jen-Shin authored
      297b424f
    • Sean McGivern's avatar
      Remove issuable finder count caching · e7817fc1
      Sean McGivern authored
      We're going to cache the total open count separately, and then just perform
      these counts on the list. We already do that to get the pagination information,
      through Kaminari, and a future change will make Kaminari reuse the query results
      from earlier in the request.
      e7817fc1