BigW Consortium Gitlab

  1. 19 Feb, 2016 3 commits
  2. 18 Feb, 2016 1 commit
  3. 10 Feb, 2016 2 commits
  4. 04 Feb, 2016 1 commit
  5. 01 Feb, 2016 1 commit
    • Optimize fetching issues closed by a merge request · 99492d6b
      Yorick Peterse authored
      Instead of running ClosingIssueExtractor for every commit in a merge
      request we can gather all the commit messages (and the merge request
      description), concatenate all this together and then run
      ClosingIssueExtractor only once.
      
      The result of this is that MergeRequest#closes_issues is now between
      3.5x and 4x faster than the old setup. Using a merge request with 10
      commits (each referencing a number of issues to close) this reduced the
      call duration from around 200 milliseconds to around 50 milliseconds.
      
      As a result of these changes the Jira related tests for
      MergeRequest#closes_issues have been removed. These tests stubbed
      Commit#closes_issues meaning that the only code that was really tested
      was the call to Array#uniq to filter out duplicate issues. As this code
      is no longer used (nor present) the corresponding tests were removed.
      
      Related: gitlab-org/gitlab-ce#12419
  6. 28 Jan, 2016 1 commit
  7. 27 Jan, 2016 1 commit
  8. 20 Jan, 2016 2 commits
  9. 19 Jan, 2016 1 commit
  10. 14 Jan, 2016 1 commit
  11. 12 Jan, 2016 1 commit
  12. 07 Jan, 2016 2 commits
  13. 06 Jan, 2016 2 commits
  14. 05 Jan, 2016 1 commit
  15. 18 Dec, 2015 1 commit
  16. 15 Dec, 2015 1 commit
  17. 08 Dec, 2015 1 commit
  18. 07 Dec, 2015 1 commit
  19. 05 Dec, 2015 1 commit
  20. 02 Dec, 2015 1 commit
  21. 01 Dec, 2015 1 commit
  22. 30 Nov, 2015 2 commits
  23. 23 Nov, 2015 2 commits
  24. 20 Nov, 2015 1 commit
  25. 19 Nov, 2015 1 commit
    • Use a JOIN in IssuableFinder#by_project · 8591cc02
      Yorick Peterse authored
      When using IssuableFinder/IssuesFinder to find issues for multiple
      projects it's more efficient to use a JOIN + a "WHERE project_id IN"
      condition opposed to running a sub-query.
      
      This change means that when finding issues without labels we're now
      using the following SQL:
      
          SELECT issues.*
          FROM issues
          JOIN projects ON projects.id = issues.project_id
      
          LEFT JOIN label_links ON label_links.target_type = 'Issue'
                                AND label_links.target_id  = issues.id
      
          WHERE (
              projects.id IN (...)
              OR projects.visibility_level IN (20, 10)
          )
          AND issues.state IN ('opened','reopened')
          AND label_links.id IS NULL
          ORDER BY issues.id DESC;
      
      instead of:
      
          SELECT issues.*
          FROM issues
          LEFT JOIN label_links ON label_links.target_type = 'Issue'
                                AND label_links.target_id  = issues.id
      
          WHERE issues.project_id IN (
              SELECT id
              FROM projects
              WHERE id IN (...)
              OR visibility_level IN (20,10)
          )
          AND issues.state IN ('opened','reopened')
          AND label_links.id IS NULL
          ORDER BY issues.id DESC;
      
      The big benefit here is that in the last case PostgreSQL can't properly
      use all available indexes. In particular it ends up performing a
      sequence scan on the "label_links" table (processing around 290 000
      rows). The new query is roughly 2x as fast as the old query.
  26. 18 Nov, 2015 1 commit
  27. 13 Nov, 2015 2 commits
  28. 02 Nov, 2015 1 commit
  29. 23 Oct, 2015 1 commit
  30. 22 Oct, 2015 1 commit
  31. 20 Oct, 2015 1 commit