Skip to content

GitLab

  • Menu
    • Projects Groups Snippets
      Help
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • G gitlabhq1
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 21
    • Issues 21
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 12
    • Merge requests 12
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • gpt
  • large_projects
  • gitlabhq1
  • Merge requests
  • !2438

Merged
Created 12 years ago by Administrator@rootOwner

Optimize query for keys of repository members

  • Overview 1
  • Commits 1
  • Changes 1

Created by: jirutka

There’re three methods in Authority module to retrieve SSH key identifiers of repository’s members, differs only in project_access role, but called all one by one from GitoliteConfig class. This generates three queries per project (e.g. when adding/removing SSH key, there’re often many projects that needs to update). Besides that these methods violates DRY principle.

We can simply query just pair of project_access and identifier (e.g. keys for all “roles” at once) and then get desired identifiers by the project_access. The query is generated three times as before, but second and third one are served from cache.

Before:

  Key Load (4.9ms)  SELECT "keys".* FROM "keys" INNER JOIN "users" ON "users"."id" = "keys"."user_id" INNER JOIN "users_projects" ON "users_projects"."user_id" = "users"."id" WHERE (users_projects.project_id = 14 AND users_projects.project_access = 20)
  Key Load (2.4ms)  SELECT "keys".* FROM "keys" WHERE "keys"."project_id" = 14
  Key Load (5.7ms)  SELECT "keys".* FROM "keys" INNER JOIN "users" ON "users"."id" = "keys"."user_id" INNER JOIN "users_projects" ON "users_projects"."user_id" = "users"."id" WHERE (users_projects.project_id = 14 AND users_projects.project_access = 30)
  Key Load (5.2ms)  SELECT "keys".* FROM "keys" INNER JOIN "users" ON "users"."id" = "keys"."user_id" INNER JOIN "users_projects" ON "users_projects"."user_id" = "users"."id" WHERE (users_projects.project_id = 14 AND users_projects.project_access = 40)
  ProtectedBranch Load (2.2ms)  SELECT "protected_branches".* FROM "protected_branches" WHERE "protected_branches"."project_id" = 14

After:

  UsersProject Load (3.1ms)  SELECT keys.identifier as key_identifier, project_access FROM "users_projects" INNER JOIN "users" ON "users"."id" = "users_projects"."user_id" INNER JOIN "keys" ON "keys"."user_id" = "users"."id" WHERE "users_projects"."project_id" = 14
   (1.8ms)  SELECT identifier FROM "keys" WHERE "keys"."project_id" = 14
  CACHE (0.0ms)  SELECT keys.identifier as key_identifier, project_access FROM "users_projects" INNER JOIN "users" ON "users"."id" = "users_projects"."user_id" INNER JOIN "keys" ON "keys"."user_id" = "users"."id" WHERE "users_projects"."project_id" = 14
  CACHE (0.0ms)  SELECT identifier FROM "keys" WHERE "keys"."project_id" = 14
  CACHE (0.0ms)  SELECT keys.identifier as key_identifier, project_access FROM "users_projects" INNER JOIN "users" ON "users"."id" = "users_projects"."user_id" INNER JOIN "keys" ON "keys"."user_id" = "users"."id" WHERE "users_projects"."project_id" = 14
  CACHE (0.1ms)  SELECT identifier FROM "keys" WHERE "keys"."project_id" = 14
  ProtectedBranch Load (1.4ms)  SELECT "protected_branches".* FROM "protected_branches" WHERE "protected_branches"."project_id" = 14

Note: I’ve run tests on my machine with MRI 1.9.3-p327 and all passed. BTW, does anyone know what’s wrong with 1.9.3-p362 that it’s segfaulting (Travis and the same on my machine)?

Loading
Loading

  • Administrator
    Administrator @root · 12 years ago
    Owner

    Created by: dzaporozhets

    Nice one. P.s. i dont know whats wrong with 362

    By Administrator on 2012-12-31T08:14:57 (imported from GitLab project)

  • You're only seeing other activity in the feed. To add a comment, switch to one of the following options.
Please register or sign in to reply
0 Assignees
None
Assign to
0 Reviewers
None
Request review from
Milestone
No milestone
None
None
Time tracking
No estimate or time spent
0
Labels
None
Assign labels
  • No matching results
  • Manage project labels
Lock merge request
Unlocked
1
1 participant
user avatar
Reference: gpt/large_projects/gitlabhq1!2438
Source branch: github/fork/jirutka/query-perf

    0 pending comments

Menu

Projects Groups Snippets
Help