1. 19 Oct, 2016 3 commits
  2. 30 Sep, 2016 1 commit
  3. 20 Sep, 2016 1 commit
  4. 30 Aug, 2016 1 commit
  5. 01 Aug, 2016 1 commit
    • zs's avatar
      State specific default sort order for issuables · cb4c5d66724c
      zs authored
      Provide more sensible default sort order for issues and merge requests
      based on the following table:
      
      | type           | state  | default sort order |
      |----------------|--------|--------------------|
      | issues         | open   | last created       |
      | issues         | closed | last updated       |
      | issues         | all    | last created       |
      | merge requests | open   | last created       |
      | merge requests | merged | last updated       |
      | merge requests | closed | last updated       |
      | merge requests | all    | last created       |
      cb4c5d66724c
  6. 06 Jun, 2016 2 commits
  7. 03 Jun, 2016 2 commits
  8. 31 May, 2016 1 commit
  9. 24 May, 2016 2 commits
  10. 16 May, 2016 1 commit
    • Sean McGivern's avatar
      Make upcoming milestone work across projects · 6dcb77744929
      Sean McGivern authored
      Before: we took the next milestone due across all projects in the
      search and found issues whose milestone title matched that
      one. Problems:
      
      1. The milestone could be closed.
      2. Different projects have milestones with different schedules.
      3. Different projects have milestones with different titles.
      4. Different projects can have milestones with different schedules, but
         the _same_ title. That means we could show issues from a past
         milestone, or one that's far in the future.
      
      After: gather the ID of the next milestone on each project we're looking
      at, and find issues with those milestone IDs. Problems:
      
      1. For a lot of projects, this can return a lot of IDs.
      2. The SQL query has to be different between Postgres and MySQL, because
         MySQL is much more lenient with HAVING: as well as the columns
         appearing in GROUP BY or in aggregate clauses, MySQL allows them to
         appear in the SELECT list (un-aggregated).
      6dcb77744929
  11. 21 Apr, 2016 1 commit
  12. 20 Apr, 2016 7 commits
  13. 19 Apr, 2016 1 commit
  14. 13 Apr, 2016 1 commit
  15. 29 Mar, 2016 2 commits
  16. 21 Mar, 2016 1 commit
  17. 20 Mar, 2016 2 commits
  18. 13 Mar, 2016 1 commit
  19. 12 Mar, 2016 3 commits
  20. 07 Mar, 2016 1 commit
  21. 19 Feb, 2016 2 commits
  22. 18 Jan, 2016 1 commit
    • Yorick Peterse's avatar
      Scope issue projects to a Group when possible · a697e5509ced
      Yorick Peterse authored
      When using IssuableFinder with a Group we can greatly reduce the amount
      of projects operated on (due to not including all public/internal
      projects) by simply passing it down to the ProjectsFinder class.
      
      This reduces the timings of the involved queries from roughly 300
      ms to roughly 20 ms.
      
      Fixes gitlab-org/gitlab-ce#4071, gitlab-org/gitlab-ce#3707
      a697e5509ced
  23. 07 Jan, 2016 1 commit
    • Yorick Peterse's avatar
      Drop projects order in IssuableFinder · 1a747a96baaa
      Yorick Peterse authored
      When grabbing the projects to filter issues by we don't care about the
      order they're returned in. By removing the ORDER BY the resulting query
      can be quite a bit faster.
      1a747a96baaa
  24. 19 Nov, 2015 1 commit
    • Yorick Peterse's avatar
      Use a JOIN in IssuableFinder#by_project · f3f59f405f70
      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.
      f3f59f405f70