An error occurred fetching the project authors.
  1. 12 Jan, 2016 1 commit
  2. 07 Jan, 2016 2 commits
  3. 06 Jan, 2016 2 commits
  4. 05 Jan, 2016 1 commit
  5. 18 Dec, 2015 1 commit
  6. 15 Dec, 2015 1 commit
  7. 08 Dec, 2015 1 commit
  8. 07 Dec, 2015 1 commit
  9. 05 Dec, 2015 1 commit
  10. 02 Dec, 2015 1 commit
  11. 01 Dec, 2015 1 commit
  12. 30 Nov, 2015 2 commits
  13. 23 Nov, 2015 1 commit
  14. 20 Nov, 2015 1 commit
  15. 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
  16. 18 Nov, 2015 1 commit
  17. 13 Nov, 2015 2 commits
  18. 02 Nov, 2015 1 commit
  19. 23 Oct, 2015 1 commit
  20. 22 Oct, 2015 1 commit
  21. 20 Oct, 2015 1 commit
  22. 16 Oct, 2015 2 commits
  23. 08 Oct, 2015 2 commits
  24. 21 Sep, 2015 1 commit
  25. 06 Sep, 2015 1 commit
  26. 11 Aug, 2015 5 commits
  27. 07 Aug, 2015 1 commit
  28. 22 Jul, 2015 1 commit
  29. 16 Jul, 2015 1 commit
  30. 15 Jul, 2015 1 commit