2018-09-11 15:08:34 -04:00
|
|
|
# frozen_string_literal: true
|
|
|
|
|
Rewrite SnippetsFinder to improve performance
This completely rewrites the SnippetsFinder class from the ground up in
order to improve its performance. The old code was beyond salvaging. It
was complex, included various Rails 5 workarounds, comments that
shouldn't be necessary, and most important of all: it produced a really
poorly performing database query.
As a result, I opted for rewriting the finder from scratch, instead of
trying to patch the existing code. Instead of trying to reuse as many
existing methods as possible, I opted for defining new methods
specifically meant for the SnippetsFinder. This requires some extra code
here and there, but allows us to have much more control over the
resulting SQL queries. It is these changes that then allow us to produce
a _much_ more efficient query.
To illustrate how bad the old query was, we will use my own snippets as
an example. Currently I have 52 snippets, most of which are global ones.
To retrieve these, you would run the following Ruby code:
user = User.find_by(username: 'yorickpeterse')
SnippetsFinder.new(user, author: user).execute
On GitLab.com the resulting query will take between 10 and 15 seconds to
run, producing the query plan found at
https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
the total number of buffers (the sum of all shared hits) is around 185
GB, though the real number is probably (hopefully) much lower as I doubt
simply summing these numbers produces the true total number of buffers
used.
The new query's plan can be found at https://explain.depesz.com/s/wHdN,
and this query takes between 10 and 100-ish milliseconds to run. The
total number of buffers used is only about 30 MB.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
2018-10-25 11:35:31 -04:00
|
|
|
# Finder for retrieving snippets that a user can see, optionally scoped to a
|
|
|
|
# project or snippets author.
|
2018-01-18 11:07:06 -05:00
|
|
|
#
|
Rewrite SnippetsFinder to improve performance
This completely rewrites the SnippetsFinder class from the ground up in
order to improve its performance. The old code was beyond salvaging. It
was complex, included various Rails 5 workarounds, comments that
shouldn't be necessary, and most important of all: it produced a really
poorly performing database query.
As a result, I opted for rewriting the finder from scratch, instead of
trying to patch the existing code. Instead of trying to reuse as many
existing methods as possible, I opted for defining new methods
specifically meant for the SnippetsFinder. This requires some extra code
here and there, but allows us to have much more control over the
resulting SQL queries. It is these changes that then allow us to produce
a _much_ more efficient query.
To illustrate how bad the old query was, we will use my own snippets as
an example. Currently I have 52 snippets, most of which are global ones.
To retrieve these, you would run the following Ruby code:
user = User.find_by(username: 'yorickpeterse')
SnippetsFinder.new(user, author: user).execute
On GitLab.com the resulting query will take between 10 and 15 seconds to
run, producing the query plan found at
https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
the total number of buffers (the sum of all shared hits) is around 185
GB, though the real number is probably (hopefully) much lower as I doubt
simply summing these numbers produces the true total number of buffers
used.
The new query's plan can be found at https://explain.depesz.com/s/wHdN,
and this query takes between 10 and 100-ish milliseconds to run. The
total number of buffers used is only about 30 MB.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
2018-10-25 11:35:31 -04:00
|
|
|
# Basic usage:
|
2018-01-18 11:07:06 -05:00
|
|
|
#
|
Rewrite SnippetsFinder to improve performance
This completely rewrites the SnippetsFinder class from the ground up in
order to improve its performance. The old code was beyond salvaging. It
was complex, included various Rails 5 workarounds, comments that
shouldn't be necessary, and most important of all: it produced a really
poorly performing database query.
As a result, I opted for rewriting the finder from scratch, instead of
trying to patch the existing code. Instead of trying to reuse as many
existing methods as possible, I opted for defining new methods
specifically meant for the SnippetsFinder. This requires some extra code
here and there, but allows us to have much more control over the
resulting SQL queries. It is these changes that then allow us to produce
a _much_ more efficient query.
To illustrate how bad the old query was, we will use my own snippets as
an example. Currently I have 52 snippets, most of which are global ones.
To retrieve these, you would run the following Ruby code:
user = User.find_by(username: 'yorickpeterse')
SnippetsFinder.new(user, author: user).execute
On GitLab.com the resulting query will take between 10 and 15 seconds to
run, producing the query plan found at
https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
the total number of buffers (the sum of all shared hits) is around 185
GB, though the real number is probably (hopefully) much lower as I doubt
simply summing these numbers produces the true total number of buffers
used.
The new query's plan can be found at https://explain.depesz.com/s/wHdN,
and this query takes between 10 and 100-ish milliseconds to run. The
total number of buffers used is only about 30 MB.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
2018-10-25 11:35:31 -04:00
|
|
|
# user = User.find(1)
|
2018-01-18 11:07:06 -05:00
|
|
|
#
|
Rewrite SnippetsFinder to improve performance
This completely rewrites the SnippetsFinder class from the ground up in
order to improve its performance. The old code was beyond salvaging. It
was complex, included various Rails 5 workarounds, comments that
shouldn't be necessary, and most important of all: it produced a really
poorly performing database query.
As a result, I opted for rewriting the finder from scratch, instead of
trying to patch the existing code. Instead of trying to reuse as many
existing methods as possible, I opted for defining new methods
specifically meant for the SnippetsFinder. This requires some extra code
here and there, but allows us to have much more control over the
resulting SQL queries. It is these changes that then allow us to produce
a _much_ more efficient query.
To illustrate how bad the old query was, we will use my own snippets as
an example. Currently I have 52 snippets, most of which are global ones.
To retrieve these, you would run the following Ruby code:
user = User.find_by(username: 'yorickpeterse')
SnippetsFinder.new(user, author: user).execute
On GitLab.com the resulting query will take between 10 and 15 seconds to
run, producing the query plan found at
https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
the total number of buffers (the sum of all shared hits) is around 185
GB, though the real number is probably (hopefully) much lower as I doubt
simply summing these numbers produces the true total number of buffers
used.
The new query's plan can be found at https://explain.depesz.com/s/wHdN,
and this query takes between 10 and 100-ish milliseconds to run. The
total number of buffers used is only about 30 MB.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
2018-10-25 11:35:31 -04:00
|
|
|
# SnippetsFinder.new(user).execute
|
2018-01-18 11:07:06 -05:00
|
|
|
#
|
Rewrite SnippetsFinder to improve performance
This completely rewrites the SnippetsFinder class from the ground up in
order to improve its performance. The old code was beyond salvaging. It
was complex, included various Rails 5 workarounds, comments that
shouldn't be necessary, and most important of all: it produced a really
poorly performing database query.
As a result, I opted for rewriting the finder from scratch, instead of
trying to patch the existing code. Instead of trying to reuse as many
existing methods as possible, I opted for defining new methods
specifically meant for the SnippetsFinder. This requires some extra code
here and there, but allows us to have much more control over the
resulting SQL queries. It is these changes that then allow us to produce
a _much_ more efficient query.
To illustrate how bad the old query was, we will use my own snippets as
an example. Currently I have 52 snippets, most of which are global ones.
To retrieve these, you would run the following Ruby code:
user = User.find_by(username: 'yorickpeterse')
SnippetsFinder.new(user, author: user).execute
On GitLab.com the resulting query will take between 10 and 15 seconds to
run, producing the query plan found at
https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
the total number of buffers (the sum of all shared hits) is around 185
GB, though the real number is probably (hopefully) much lower as I doubt
simply summing these numbers produces the true total number of buffers
used.
The new query's plan can be found at https://explain.depesz.com/s/wHdN,
and this query takes between 10 and 100-ish milliseconds to run. The
total number of buffers used is only about 30 MB.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
2018-10-25 11:35:31 -04:00
|
|
|
# To limit the snippets to a specific project, supply the `project:` option:
|
|
|
|
#
|
|
|
|
# user = User.find(1)
|
|
|
|
# project = Project.find(1)
|
|
|
|
#
|
|
|
|
# SnippetsFinder.new(user, project: project).execute
|
|
|
|
#
|
|
|
|
# Limiting snippets to an author can be done by supplying the `author:` option:
|
|
|
|
#
|
|
|
|
# user = User.find(1)
|
|
|
|
# project = Project.find(1)
|
|
|
|
#
|
|
|
|
# SnippetsFinder.new(user, author: user).execute
|
|
|
|
#
|
|
|
|
# To filter snippets using a specific visibility level, you can provide the
|
|
|
|
# `scope:` option:
|
|
|
|
#
|
|
|
|
# user = User.find(1)
|
|
|
|
# project = Project.find(1)
|
|
|
|
#
|
|
|
|
# SnippetsFinder.new(user, author: user, scope: :are_public).execute
|
|
|
|
#
|
|
|
|
# Valid `scope:` values are:
|
|
|
|
#
|
|
|
|
# * `:are_private`
|
|
|
|
# * `:are_internal`
|
|
|
|
# * `:are_public`
|
|
|
|
#
|
|
|
|
# Any other value will be ignored.
|
2017-04-28 18:06:27 -04:00
|
|
|
class SnippetsFinder < UnionFinder
|
2017-12-11 09:21:06 -05:00
|
|
|
include FinderMethods
|
2019-11-28 10:06:57 -05:00
|
|
|
include Gitlab::Utils::StrongMemoize
|
2017-12-11 09:21:06 -05:00
|
|
|
|
2019-11-28 10:06:57 -05:00
|
|
|
attr_accessor :current_user, :params
|
2020-07-10 14:09:45 -04:00
|
|
|
delegate :explore, :only_personal, :only_project, :scope, :sort, to: :params
|
2017-04-28 18:06:27 -04:00
|
|
|
|
Rewrite SnippetsFinder to improve performance
This completely rewrites the SnippetsFinder class from the ground up in
order to improve its performance. The old code was beyond salvaging. It
was complex, included various Rails 5 workarounds, comments that
shouldn't be necessary, and most important of all: it produced a really
poorly performing database query.
As a result, I opted for rewriting the finder from scratch, instead of
trying to patch the existing code. Instead of trying to reuse as many
existing methods as possible, I opted for defining new methods
specifically meant for the SnippetsFinder. This requires some extra code
here and there, but allows us to have much more control over the
resulting SQL queries. It is these changes that then allow us to produce
a _much_ more efficient query.
To illustrate how bad the old query was, we will use my own snippets as
an example. Currently I have 52 snippets, most of which are global ones.
To retrieve these, you would run the following Ruby code:
user = User.find_by(username: 'yorickpeterse')
SnippetsFinder.new(user, author: user).execute
On GitLab.com the resulting query will take between 10 and 15 seconds to
run, producing the query plan found at
https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
the total number of buffers (the sum of all shared hits) is around 185
GB, though the real number is probably (hopefully) much lower as I doubt
simply summing these numbers produces the true total number of buffers
used.
The new query's plan can be found at https://explain.depesz.com/s/wHdN,
and this query takes between 10 and 100-ish milliseconds to run. The
total number of buffers used is only about 30 MB.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
2018-10-25 11:35:31 -04:00
|
|
|
def initialize(current_user = nil, params = {})
|
2017-04-28 18:06:27 -04:00
|
|
|
@current_user = current_user
|
2019-11-28 10:06:57 -05:00
|
|
|
@params = OpenStruct.new(params)
|
Rewrite SnippetsFinder to improve performance
This completely rewrites the SnippetsFinder class from the ground up in
order to improve its performance. The old code was beyond salvaging. It
was complex, included various Rails 5 workarounds, comments that
shouldn't be necessary, and most important of all: it produced a really
poorly performing database query.
As a result, I opted for rewriting the finder from scratch, instead of
trying to patch the existing code. Instead of trying to reuse as many
existing methods as possible, I opted for defining new methods
specifically meant for the SnippetsFinder. This requires some extra code
here and there, but allows us to have much more control over the
resulting SQL queries. It is these changes that then allow us to produce
a _much_ more efficient query.
To illustrate how bad the old query was, we will use my own snippets as
an example. Currently I have 52 snippets, most of which are global ones.
To retrieve these, you would run the following Ruby code:
user = User.find_by(username: 'yorickpeterse')
SnippetsFinder.new(user, author: user).execute
On GitLab.com the resulting query will take between 10 and 15 seconds to
run, producing the query plan found at
https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
the total number of buffers (the sum of all shared hits) is around 185
GB, though the real number is probably (hopefully) much lower as I doubt
simply summing these numbers produces the true total number of buffers
used.
The new query's plan can be found at https://explain.depesz.com/s/wHdN,
and this query takes between 10 and 100-ish milliseconds to run. The
total number of buffers used is only about 30 MB.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
2018-10-25 11:35:31 -04:00
|
|
|
|
|
|
|
if project && author
|
|
|
|
raise(
|
|
|
|
ArgumentError,
|
|
|
|
'Filtering by both an author and a project is not supported, ' \
|
|
|
|
'as this finder is not optimised for this use case'
|
|
|
|
)
|
2018-01-18 11:07:06 -05:00
|
|
|
end
|
|
|
|
end
|
2017-04-28 18:06:27 -04:00
|
|
|
|
Rewrite SnippetsFinder to improve performance
This completely rewrites the SnippetsFinder class from the ground up in
order to improve its performance. The old code was beyond salvaging. It
was complex, included various Rails 5 workarounds, comments that
shouldn't be necessary, and most important of all: it produced a really
poorly performing database query.
As a result, I opted for rewriting the finder from scratch, instead of
trying to patch the existing code. Instead of trying to reuse as many
existing methods as possible, I opted for defining new methods
specifically meant for the SnippetsFinder. This requires some extra code
here and there, but allows us to have much more control over the
resulting SQL queries. It is these changes that then allow us to produce
a _much_ more efficient query.
To illustrate how bad the old query was, we will use my own snippets as
an example. Currently I have 52 snippets, most of which are global ones.
To retrieve these, you would run the following Ruby code:
user = User.find_by(username: 'yorickpeterse')
SnippetsFinder.new(user, author: user).execute
On GitLab.com the resulting query will take between 10 and 15 seconds to
run, producing the query plan found at
https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
the total number of buffers (the sum of all shared hits) is around 185
GB, though the real number is probably (hopefully) much lower as I doubt
simply summing these numbers produces the true total number of buffers
used.
The new query's plan can be found at https://explain.depesz.com/s/wHdN,
and this query takes between 10 and 100-ish milliseconds to run. The
total number of buffers used is only about 30 MB.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
2018-10-25 11:35:31 -04:00
|
|
|
def execute
|
2019-11-28 10:06:57 -05:00
|
|
|
# The snippet query can be expensive, therefore if the
|
|
|
|
# author or project params have been passed and they don't
|
2020-03-03 16:08:37 -05:00
|
|
|
# exist, or if a Project has been passed and has snippets
|
|
|
|
# disabled, it's better to return
|
2019-11-28 10:06:57 -05:00
|
|
|
return Snippet.none if author.nil? && params[:author].present?
|
|
|
|
return Snippet.none if project.nil? && params[:project].present?
|
2020-03-03 16:08:37 -05:00
|
|
|
return Snippet.none if project && !project.feature_available?(:snippets, current_user)
|
2019-11-28 10:06:57 -05:00
|
|
|
|
|
|
|
items = init_collection
|
|
|
|
items = by_ids(items)
|
2020-07-10 14:09:45 -04:00
|
|
|
items = items.with_optional_visibility(visibility_from_scope)
|
|
|
|
|
|
|
|
items.order_by(sort_param)
|
2018-01-18 11:07:06 -05:00
|
|
|
end
|
2014-10-08 09:44:25 -04:00
|
|
|
|
2019-03-05 11:12:27 -05:00
|
|
|
private
|
|
|
|
|
2019-10-09 11:05:58 -04:00
|
|
|
def init_collection
|
2019-10-18 14:06:21 -04:00
|
|
|
if explore
|
|
|
|
snippets_for_explore
|
2019-11-28 10:06:57 -05:00
|
|
|
elsif only_personal
|
|
|
|
personal_snippets
|
2019-10-18 14:06:21 -04:00
|
|
|
elsif project
|
2019-10-09 11:05:58 -04:00
|
|
|
snippets_for_a_single_project
|
|
|
|
else
|
2019-11-28 10:06:57 -05:00
|
|
|
snippets_for_personal_and_multiple_projects
|
2019-10-09 11:05:58 -04:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2019-10-18 14:06:21 -04:00
|
|
|
# Produces a query that retrieves snippets for the Explore page
|
|
|
|
#
|
|
|
|
# We only show personal snippets here because this page is meant for
|
|
|
|
# discovery, and project snippets are of limited interest here.
|
|
|
|
def snippets_for_explore
|
|
|
|
Snippet.public_to_user(current_user).only_personal_snippets
|
|
|
|
end
|
|
|
|
|
Rewrite SnippetsFinder to improve performance
This completely rewrites the SnippetsFinder class from the ground up in
order to improve its performance. The old code was beyond salvaging. It
was complex, included various Rails 5 workarounds, comments that
shouldn't be necessary, and most important of all: it produced a really
poorly performing database query.
As a result, I opted for rewriting the finder from scratch, instead of
trying to patch the existing code. Instead of trying to reuse as many
existing methods as possible, I opted for defining new methods
specifically meant for the SnippetsFinder. This requires some extra code
here and there, but allows us to have much more control over the
resulting SQL queries. It is these changes that then allow us to produce
a _much_ more efficient query.
To illustrate how bad the old query was, we will use my own snippets as
an example. Currently I have 52 snippets, most of which are global ones.
To retrieve these, you would run the following Ruby code:
user = User.find_by(username: 'yorickpeterse')
SnippetsFinder.new(user, author: user).execute
On GitLab.com the resulting query will take between 10 and 15 seconds to
run, producing the query plan found at
https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
the total number of buffers (the sum of all shared hits) is around 185
GB, though the real number is probably (hopefully) much lower as I doubt
simply summing these numbers produces the true total number of buffers
used.
The new query's plan can be found at https://explain.depesz.com/s/wHdN,
and this query takes between 10 and 100-ish milliseconds to run. The
total number of buffers used is only about 30 MB.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
2018-10-25 11:35:31 -04:00
|
|
|
# Produces a query that retrieves snippets from multiple projects.
|
2018-03-02 03:29:12 -05:00
|
|
|
#
|
Rewrite SnippetsFinder to improve performance
This completely rewrites the SnippetsFinder class from the ground up in
order to improve its performance. The old code was beyond salvaging. It
was complex, included various Rails 5 workarounds, comments that
shouldn't be necessary, and most important of all: it produced a really
poorly performing database query.
As a result, I opted for rewriting the finder from scratch, instead of
trying to patch the existing code. Instead of trying to reuse as many
existing methods as possible, I opted for defining new methods
specifically meant for the SnippetsFinder. This requires some extra code
here and there, but allows us to have much more control over the
resulting SQL queries. It is these changes that then allow us to produce
a _much_ more efficient query.
To illustrate how bad the old query was, we will use my own snippets as
an example. Currently I have 52 snippets, most of which are global ones.
To retrieve these, you would run the following Ruby code:
user = User.find_by(username: 'yorickpeterse')
SnippetsFinder.new(user, author: user).execute
On GitLab.com the resulting query will take between 10 and 15 seconds to
run, producing the query plan found at
https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
the total number of buffers (the sum of all shared hits) is around 185
GB, though the real number is probably (hopefully) much lower as I doubt
simply summing these numbers produces the true total number of buffers
used.
The new query's plan can be found at https://explain.depesz.com/s/wHdN,
and this query takes between 10 and 100-ish milliseconds to run. The
total number of buffers used is only about 30 MB.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
2018-10-25 11:35:31 -04:00
|
|
|
# The resulting query will, depending on the user's permissions, include the
|
|
|
|
# following collections of snippets:
|
|
|
|
#
|
|
|
|
# 1. Snippets that don't belong to any project.
|
|
|
|
# 2. Snippets of projects that are visible to the current user (e.g. snippets
|
|
|
|
# in public projects).
|
|
|
|
# 3. Snippets of projects that the current user is a member of.
|
|
|
|
#
|
|
|
|
# Each collection is constructed in isolation, allowing for greater control
|
|
|
|
# over the resulting SQL query.
|
2019-11-28 10:06:57 -05:00
|
|
|
def snippets_for_personal_and_multiple_projects
|
|
|
|
queries = []
|
|
|
|
queries << personal_snippets unless only_project
|
Rewrite SnippetsFinder to improve performance
This completely rewrites the SnippetsFinder class from the ground up in
order to improve its performance. The old code was beyond salvaging. It
was complex, included various Rails 5 workarounds, comments that
shouldn't be necessary, and most important of all: it produced a really
poorly performing database query.
As a result, I opted for rewriting the finder from scratch, instead of
trying to patch the existing code. Instead of trying to reuse as many
existing methods as possible, I opted for defining new methods
specifically meant for the SnippetsFinder. This requires some extra code
here and there, but allows us to have much more control over the
resulting SQL queries. It is these changes that then allow us to produce
a _much_ more efficient query.
To illustrate how bad the old query was, we will use my own snippets as
an example. Currently I have 52 snippets, most of which are global ones.
To retrieve these, you would run the following Ruby code:
user = User.find_by(username: 'yorickpeterse')
SnippetsFinder.new(user, author: user).execute
On GitLab.com the resulting query will take between 10 and 15 seconds to
run, producing the query plan found at
https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
the total number of buffers (the sum of all shared hits) is around 185
GB, though the real number is probably (hopefully) much lower as I doubt
simply summing these numbers produces the true total number of buffers
used.
The new query's plan can be found at https://explain.depesz.com/s/wHdN,
and this query takes between 10 and 100-ish milliseconds to run. The
total number of buffers used is only about 30 MB.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
2018-10-25 11:35:31 -04:00
|
|
|
|
|
|
|
if Ability.allowed?(current_user, :read_cross_project)
|
|
|
|
queries << snippets_of_visible_projects
|
|
|
|
queries << snippets_of_authorized_projects if current_user
|
|
|
|
end
|
2018-02-16 10:05:32 -05:00
|
|
|
|
2020-07-13 11:09:08 -04:00
|
|
|
prepared_union(queries)
|
2014-10-08 09:44:25 -04:00
|
|
|
end
|
|
|
|
|
Rewrite SnippetsFinder to improve performance
This completely rewrites the SnippetsFinder class from the ground up in
order to improve its performance. The old code was beyond salvaging. It
was complex, included various Rails 5 workarounds, comments that
shouldn't be necessary, and most important of all: it produced a really
poorly performing database query.
As a result, I opted for rewriting the finder from scratch, instead of
trying to patch the existing code. Instead of trying to reuse as many
existing methods as possible, I opted for defining new methods
specifically meant for the SnippetsFinder. This requires some extra code
here and there, but allows us to have much more control over the
resulting SQL queries. It is these changes that then allow us to produce
a _much_ more efficient query.
To illustrate how bad the old query was, we will use my own snippets as
an example. Currently I have 52 snippets, most of which are global ones.
To retrieve these, you would run the following Ruby code:
user = User.find_by(username: 'yorickpeterse')
SnippetsFinder.new(user, author: user).execute
On GitLab.com the resulting query will take between 10 and 15 seconds to
run, producing the query plan found at
https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
the total number of buffers (the sum of all shared hits) is around 185
GB, though the real number is probably (hopefully) much lower as I doubt
simply summing these numbers produces the true total number of buffers
used.
The new query's plan can be found at https://explain.depesz.com/s/wHdN,
and this query takes between 10 and 100-ish milliseconds to run. The
total number of buffers used is only about 30 MB.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
2018-10-25 11:35:31 -04:00
|
|
|
def snippets_for_a_single_project
|
|
|
|
Snippet.for_project_with_user(project, current_user)
|
2018-01-18 11:07:06 -05:00
|
|
|
end
|
|
|
|
|
2019-10-18 14:06:21 -04:00
|
|
|
def personal_snippets
|
|
|
|
snippets_for_author_or_visible_to_user.only_personal_snippets
|
2017-04-28 18:06:27 -04:00
|
|
|
end
|
2014-10-08 09:44:25 -04:00
|
|
|
|
Rewrite SnippetsFinder to improve performance
This completely rewrites the SnippetsFinder class from the ground up in
order to improve its performance. The old code was beyond salvaging. It
was complex, included various Rails 5 workarounds, comments that
shouldn't be necessary, and most important of all: it produced a really
poorly performing database query.
As a result, I opted for rewriting the finder from scratch, instead of
trying to patch the existing code. Instead of trying to reuse as many
existing methods as possible, I opted for defining new methods
specifically meant for the SnippetsFinder. This requires some extra code
here and there, but allows us to have much more control over the
resulting SQL queries. It is these changes that then allow us to produce
a _much_ more efficient query.
To illustrate how bad the old query was, we will use my own snippets as
an example. Currently I have 52 snippets, most of which are global ones.
To retrieve these, you would run the following Ruby code:
user = User.find_by(username: 'yorickpeterse')
SnippetsFinder.new(user, author: user).execute
On GitLab.com the resulting query will take between 10 and 15 seconds to
run, producing the query plan found at
https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
the total number of buffers (the sum of all shared hits) is around 185
GB, though the real number is probably (hopefully) much lower as I doubt
simply summing these numbers produces the true total number of buffers
used.
The new query's plan can be found at https://explain.depesz.com/s/wHdN,
and this query takes between 10 and 100-ish milliseconds to run. The
total number of buffers used is only about 30 MB.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
2018-10-25 11:35:31 -04:00
|
|
|
# Returns the snippets that the current user (logged in or not) can view.
|
|
|
|
def snippets_of_visible_projects
|
|
|
|
snippets_for_author_or_visible_to_user
|
|
|
|
.only_include_projects_visible_to(current_user)
|
|
|
|
.only_include_projects_with_snippets_enabled
|
|
|
|
end
|
2017-04-28 18:06:27 -04:00
|
|
|
|
Rewrite SnippetsFinder to improve performance
This completely rewrites the SnippetsFinder class from the ground up in
order to improve its performance. The old code was beyond salvaging. It
was complex, included various Rails 5 workarounds, comments that
shouldn't be necessary, and most important of all: it produced a really
poorly performing database query.
As a result, I opted for rewriting the finder from scratch, instead of
trying to patch the existing code. Instead of trying to reuse as many
existing methods as possible, I opted for defining new methods
specifically meant for the SnippetsFinder. This requires some extra code
here and there, but allows us to have much more control over the
resulting SQL queries. It is these changes that then allow us to produce
a _much_ more efficient query.
To illustrate how bad the old query was, we will use my own snippets as
an example. Currently I have 52 snippets, most of which are global ones.
To retrieve these, you would run the following Ruby code:
user = User.find_by(username: 'yorickpeterse')
SnippetsFinder.new(user, author: user).execute
On GitLab.com the resulting query will take between 10 and 15 seconds to
run, producing the query plan found at
https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
the total number of buffers (the sum of all shared hits) is around 185
GB, though the real number is probably (hopefully) much lower as I doubt
simply summing these numbers produces the true total number of buffers
used.
The new query's plan can be found at https://explain.depesz.com/s/wHdN,
and this query takes between 10 and 100-ish milliseconds to run. The
total number of buffers used is only about 30 MB.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
2018-10-25 11:35:31 -04:00
|
|
|
# Returns the snippets that the currently logged in user has access to by
|
|
|
|
# being a member of the project the snippets belong to.
|
|
|
|
#
|
|
|
|
# This method requires that `current_user` returns a `User` instead of `nil`,
|
|
|
|
# and is optimised for this specific scenario.
|
|
|
|
def snippets_of_authorized_projects
|
2019-10-09 11:05:58 -04:00
|
|
|
base = author ? author.snippets : Snippet.all
|
Rewrite SnippetsFinder to improve performance
This completely rewrites the SnippetsFinder class from the ground up in
order to improve its performance. The old code was beyond salvaging. It
was complex, included various Rails 5 workarounds, comments that
shouldn't be necessary, and most important of all: it produced a really
poorly performing database query.
As a result, I opted for rewriting the finder from scratch, instead of
trying to patch the existing code. Instead of trying to reuse as many
existing methods as possible, I opted for defining new methods
specifically meant for the SnippetsFinder. This requires some extra code
here and there, but allows us to have much more control over the
resulting SQL queries. It is these changes that then allow us to produce
a _much_ more efficient query.
To illustrate how bad the old query was, we will use my own snippets as
an example. Currently I have 52 snippets, most of which are global ones.
To retrieve these, you would run the following Ruby code:
user = User.find_by(username: 'yorickpeterse')
SnippetsFinder.new(user, author: user).execute
On GitLab.com the resulting query will take between 10 and 15 seconds to
run, producing the query plan found at
https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
the total number of buffers (the sum of all shared hits) is around 185
GB, though the real number is probably (hopefully) much lower as I doubt
simply summing these numbers produces the true total number of buffers
used.
The new query's plan can be found at https://explain.depesz.com/s/wHdN,
and this query takes between 10 and 100-ish milliseconds to run. The
total number of buffers used is only about 30 MB.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
2018-10-25 11:35:31 -04:00
|
|
|
|
|
|
|
base
|
|
|
|
.only_include_projects_with_snippets_enabled(include_private: true)
|
|
|
|
.only_include_authorized_projects(current_user)
|
|
|
|
end
|
2017-04-28 18:06:27 -04:00
|
|
|
|
Rewrite SnippetsFinder to improve performance
This completely rewrites the SnippetsFinder class from the ground up in
order to improve its performance. The old code was beyond salvaging. It
was complex, included various Rails 5 workarounds, comments that
shouldn't be necessary, and most important of all: it produced a really
poorly performing database query.
As a result, I opted for rewriting the finder from scratch, instead of
trying to patch the existing code. Instead of trying to reuse as many
existing methods as possible, I opted for defining new methods
specifically meant for the SnippetsFinder. This requires some extra code
here and there, but allows us to have much more control over the
resulting SQL queries. It is these changes that then allow us to produce
a _much_ more efficient query.
To illustrate how bad the old query was, we will use my own snippets as
an example. Currently I have 52 snippets, most of which are global ones.
To retrieve these, you would run the following Ruby code:
user = User.find_by(username: 'yorickpeterse')
SnippetsFinder.new(user, author: user).execute
On GitLab.com the resulting query will take between 10 and 15 seconds to
run, producing the query plan found at
https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
the total number of buffers (the sum of all shared hits) is around 185
GB, though the real number is probably (hopefully) much lower as I doubt
simply summing these numbers produces the true total number of buffers
used.
The new query's plan can be found at https://explain.depesz.com/s/wHdN,
and this query takes between 10 and 100-ish milliseconds to run. The
total number of buffers used is only about 30 MB.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
2018-10-25 11:35:31 -04:00
|
|
|
def snippets_for_author_or_visible_to_user
|
|
|
|
if author
|
|
|
|
snippets_for_author
|
|
|
|
elsif current_user
|
|
|
|
Snippet.visible_to_or_authored_by(current_user)
|
|
|
|
else
|
|
|
|
Snippet.public_to_user
|
|
|
|
end
|
2017-04-28 18:06:27 -04:00
|
|
|
end
|
|
|
|
|
Rewrite SnippetsFinder to improve performance
This completely rewrites the SnippetsFinder class from the ground up in
order to improve its performance. The old code was beyond salvaging. It
was complex, included various Rails 5 workarounds, comments that
shouldn't be necessary, and most important of all: it produced a really
poorly performing database query.
As a result, I opted for rewriting the finder from scratch, instead of
trying to patch the existing code. Instead of trying to reuse as many
existing methods as possible, I opted for defining new methods
specifically meant for the SnippetsFinder. This requires some extra code
here and there, but allows us to have much more control over the
resulting SQL queries. It is these changes that then allow us to produce
a _much_ more efficient query.
To illustrate how bad the old query was, we will use my own snippets as
an example. Currently I have 52 snippets, most of which are global ones.
To retrieve these, you would run the following Ruby code:
user = User.find_by(username: 'yorickpeterse')
SnippetsFinder.new(user, author: user).execute
On GitLab.com the resulting query will take between 10 and 15 seconds to
run, producing the query plan found at
https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
the total number of buffers (the sum of all shared hits) is around 185
GB, though the real number is probably (hopefully) much lower as I doubt
simply summing these numbers produces the true total number of buffers
used.
The new query's plan can be found at https://explain.depesz.com/s/wHdN,
and this query takes between 10 and 100-ish milliseconds to run. The
total number of buffers used is only about 30 MB.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
2018-10-25 11:35:31 -04:00
|
|
|
def snippets_for_author
|
|
|
|
base = author.snippets
|
2017-04-28 18:06:27 -04:00
|
|
|
|
Rewrite SnippetsFinder to improve performance
This completely rewrites the SnippetsFinder class from the ground up in
order to improve its performance. The old code was beyond salvaging. It
was complex, included various Rails 5 workarounds, comments that
shouldn't be necessary, and most important of all: it produced a really
poorly performing database query.
As a result, I opted for rewriting the finder from scratch, instead of
trying to patch the existing code. Instead of trying to reuse as many
existing methods as possible, I opted for defining new methods
specifically meant for the SnippetsFinder. This requires some extra code
here and there, but allows us to have much more control over the
resulting SQL queries. It is these changes that then allow us to produce
a _much_ more efficient query.
To illustrate how bad the old query was, we will use my own snippets as
an example. Currently I have 52 snippets, most of which are global ones.
To retrieve these, you would run the following Ruby code:
user = User.find_by(username: 'yorickpeterse')
SnippetsFinder.new(user, author: user).execute
On GitLab.com the resulting query will take between 10 and 15 seconds to
run, producing the query plan found at
https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
the total number of buffers (the sum of all shared hits) is around 185
GB, though the real number is probably (hopefully) much lower as I doubt
simply summing these numbers produces the true total number of buffers
used.
The new query's plan can be found at https://explain.depesz.com/s/wHdN,
and this query takes between 10 and 100-ish milliseconds to run. The
total number of buffers used is only about 30 MB.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
2018-10-25 11:35:31 -04:00
|
|
|
if author == current_user
|
|
|
|
# If the current user is also the author of all snippets, then we can
|
|
|
|
# include private snippets.
|
|
|
|
base
|
|
|
|
else
|
|
|
|
base.public_to_user(current_user)
|
|
|
|
end
|
2017-04-28 18:06:27 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
def visibility_from_scope
|
2019-11-28 10:06:57 -05:00
|
|
|
case scope.to_s
|
2016-12-09 15:40:48 -05:00
|
|
|
when 'are_private'
|
2017-04-28 18:06:27 -04:00
|
|
|
Snippet::PRIVATE
|
2016-12-09 15:40:48 -05:00
|
|
|
when 'are_internal'
|
2017-04-28 18:06:27 -04:00
|
|
|
Snippet::INTERNAL
|
2016-12-09 15:40:48 -05:00
|
|
|
when 'are_public'
|
2017-04-28 18:06:27 -04:00
|
|
|
Snippet::PUBLIC
|
2016-12-09 15:40:48 -05:00
|
|
|
else
|
2017-04-28 18:06:27 -04:00
|
|
|
nil
|
2016-12-09 15:40:48 -05:00
|
|
|
end
|
|
|
|
end
|
2019-11-28 10:06:57 -05:00
|
|
|
|
|
|
|
def by_ids(items)
|
|
|
|
return items unless params[:ids].present?
|
|
|
|
|
|
|
|
items.id_in(params[:ids])
|
|
|
|
end
|
|
|
|
|
|
|
|
def author
|
|
|
|
strong_memoize(:author) do
|
|
|
|
next unless params[:author].present?
|
|
|
|
|
|
|
|
params[:author].is_a?(User) ? params[:author] : User.find_by_id(params[:author])
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
def project
|
|
|
|
strong_memoize(:project) do
|
|
|
|
next unless params[:project].present?
|
|
|
|
|
|
|
|
params[:project].is_a?(Project) ? params[:project] : Project.find_by_id(params[:project])
|
|
|
|
end
|
|
|
|
end
|
2020-07-10 14:09:45 -04:00
|
|
|
|
|
|
|
def sort_param
|
|
|
|
sort.presence || 'id_desc'
|
|
|
|
end
|
2020-07-13 11:09:08 -04:00
|
|
|
|
|
|
|
def prepared_union(queries)
|
|
|
|
return Snippet.none if queries.empty?
|
|
|
|
return queries.first if queries.length == 1
|
|
|
|
|
|
|
|
# The queries are going to be part of a global `where`
|
|
|
|
# therefore we only need to retrieve the `id` column
|
|
|
|
# which will speed the query
|
|
|
|
queries.map! { |rel| rel.select(:id) }
|
|
|
|
Snippet.id_in(find_union(queries, Snippet))
|
|
|
|
end
|
2014-10-08 09:44:25 -04:00
|
|
|
end
|
2019-10-09 11:05:58 -04:00
|
|
|
|
|
|
|
SnippetsFinder.prepend_if_ee('EE::SnippetsFinder')
|