Commit 00ed8ef7 authored by Heinrich Lee Yu's avatar Heinrich Lee Yu

Merge branch 'projects_finder_visibility_optimization' into 'master'

Improve query there is specified visibility_level

See merge request gitlab-org/gitlab!20594
parents dac1e700 5f243a63
......@@ -79,7 +79,7 @@ class ProjectsFinder < UnionFinder
elsif min_access_level?
current_user.authorized_projects(params[:min_access_level])
else
if private_only?
if private_only? || impossible_visibility_level?
current_user.authorized_projects
else
Project.public_or_visible_to_user(current_user)
......@@ -96,6 +96,30 @@ class ProjectsFinder < UnionFinder
end
end
# This is an optimization - surprisingly PostgreSQL does not optimize
# for this.
#
# If the default visiblity level and desired visiblity level filter cancels
# each other out, don't use the SQL clause for visibility level in
# `Project.public_or_visible_to_user`. In fact, this then becames equivalent
# to just authorized projects for the user.
#
# E.g.
# (EXISTS(<authorized_projects>) OR projects.visibility_level IN (10,20))
# AND "projects"."visibility_level" = 0
#
# is essentially
# EXISTS(<authorized_projects>) AND "projects"."visibility_level" = 0
#
# See https://gitlab.com/gitlab-org/gitlab/issues/37007
def impossible_visibility_level?
return unless params[:visibility_level].present?
public_visibility_levels = Gitlab::VisibilityLevel.levels_for_user(current_user)
!public_visibility_levels.include?(params[:visibility_level])
end
def owned_projects?
params[:owned].present?
end
......
---
title: Optimize query when Projects API requests private visibility level
merge_request: 20594
author:
type: performance
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment