Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
    • Help
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
GitLab Community Edition
GitLab Community Edition
  • Project
    • Project
    • Details
    • Activity
    • Releases
    • Cycle Analytics
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Charts
    • Locked Files
  • Issues 14,492
    • Issues 14,492
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 812
    • Merge Requests 812
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Charts
  • Registry
    • Registry
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Charts
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • GitLab.org
  • GitLab Community EditionGitLab Community Edition
  • Merge Requests
  • !10885

You need to sign in or sign up before continuing.
Merged
Opened Apr 24, 2017 by Yorick Peterse@yorickpeterse16 of 16 tasks completed16/16 tasks
  • Report abuse
Report abuse

Rework project authorizations and nested groups for better performance

This MR reworks the queries used for calculating project authorizations, in particular those used for getting nested groups.

TODO

  • Re-use code in Users::RefreshAuthorizedProjectsService between MySQL and PostgreSQL (as much as possible)
  • Add Group.supports_nested_groups? which returns true for PostgreSQL, false otherwise
  • In the UI use Group.supports_nested_groups? to hide nested groups related UI elements
  • Do something similar in controllers or models (depending on what the best place would be)
  • Add a migration which converts nested groups to regular groups for MySQL, making sure the right people still have access
  • Remove hierarchy related methods that use the old routes setup and are no longer necessary
  • Add documentation stating nested groups can not be supported properly on MySQL

Performance Impact

All tests were performed using the GitLab.com database, on a read-only replica.

Method Before After Notes
Namespace#descendants 580 ms ~1 ms Tests performed using the "gitlab-org" group
Namespace#ancestors ~1 ms ~1 ms Tests performed using the "sub-group-test" group. Old query was a regular index scan

Does this MR meet the acceptance criteria?

  • Changelog entry added, if necessary
  • Documentation created/updated
  • API support added
  • Tests
    • Added for this feature/bug
    • All builds are passing
  • Conform by the merge request performance guides
  • Conform by the style guides
  • Branch has no merge conflicts with master (if it does - rebase it please)
  • Squashed related commits together
Edited May 29, 2017 by Yorick Peterse
  • Discussion 113
  • Commits 6
  • Pipelines 36
  • Changes 63
Douwe Maan
Assignee
Douwe Maan @DouweM
Assign to
9.3
Milestone
9.3
Assign milestone
Time tracking
3
Labels
Platform [DEPRECATED] database performance
Assign labels
  • View project labels
Reference: gitlab-org/gitlab-ce!10885

Revert this merge request

This will create a new commit in order to revert the existing changes.

Switch branch
Cancel
A new branch will be created in your fork and a new merge request will be started.

Cherry-pick this merge request

Switch branch
Cancel
A new branch will be created in your fork and a new merge request will be started.