An error occurred fetching the project authors.
  1. 07 Jan, 2016 1 commit
    • Yorick Peterse's avatar
      Don't pluck IDs when getting issues/MRs per group · 0d0049c0
      Yorick Peterse authored
      This replaces plucking of IDs with a sub-query, saving the overhead of
      loading the data in Ruby and then mapping the rows to an Array of IDs.
      This also scales much better when dealing with a large amount of IDs
      that would be involved.
      0d0049c0
  2. 05 Jan, 2016 1 commit
  3. 18 Dec, 2015 1 commit
  4. 15 Dec, 2015 1 commit
  5. 08 Dec, 2015 1 commit
  6. 07 Dec, 2015 1 commit
  7. 05 Dec, 2015 1 commit
  8. 02 Dec, 2015 1 commit
  9. 01 Dec, 2015 1 commit
  10. 30 Nov, 2015 2 commits
  11. 23 Nov, 2015 1 commit
  12. 20 Nov, 2015 1 commit
  13. 19 Nov, 2015 1 commit
    • Yorick Peterse's avatar
      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.
      8591cc02
  14. 18 Nov, 2015 1 commit
  15. 13 Nov, 2015 2 commits
  16. 02 Nov, 2015 1 commit
  17. 23 Oct, 2015 1 commit
  18. 22 Oct, 2015 1 commit
  19. 20 Oct, 2015 1 commit
  20. 16 Oct, 2015 2 commits
  21. 08 Oct, 2015 2 commits
  22. 21 Sep, 2015 1 commit
  23. 06 Sep, 2015 1 commit
  24. 11 Aug, 2015 5 commits
  25. 07 Aug, 2015 1 commit
  26. 22 Jul, 2015 1 commit
  27. 16 Jul, 2015 1 commit
  28. 15 Jul, 2015 3 commits
  29. 01 Jul, 2015 2 commits