Age | Commit message (Collapse) | Author |
|
Remove N+1 queries in /admin/projects page
See merge request gitlab-org/gitlab-ce!17834
|
|
Fix timeouts loading /admin/projects page
Closes #44338
See merge request gitlab-org/gitlab-ce!17785
|
|
Improve database response time for listing user activity
Closes #40525
See merge request gitlab-org/gitlab-ce!17454
|
|
into 'master'
Add overview of branches and filtered views for active/stale branches
Closes #40187 et #17293
See merge request gitlab-org/gitlab-ce!15402
|
|
|
|
This was causing todo priority sorting to fail.
|
|
Resolve "API support for selecting only updated issues before/after a given date"
Closes #41616
See merge request gitlab-org/gitlab-ce!17417
|
|
|
|
|
|
Don't use ProjectsFinder in TodosFinder
Closes #43767
See merge request gitlab-org/gitlab-ce!17462
|
|
Revert Project.public_or_visible_to_user changes but apply change to SnippetsFinder
Closes #42877
See merge request gitlab-org/gitlab-ce!17476
|
|
|
|
Using ProjectsFinder in TodosFinder to limit todos to the right projects
leads to overly complicated and slow database queries. This commit
removes the use of ProjectsFinder in favour of using
Project.public_or_visible_to_current_user directly.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/43767
|
|
Because epic index page includes also epics from subgroups
it's necessary to also get descendant group labels for filtering.
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/4773#note_61236542
|
|
|
|
This applies the changes introduced in `Project.public_or_visible_to_user`
to the snippets finder only.
We know that for `SnippetsFinder`, this change improves SQL timing from
5/23/25s to 0.7/2/4s (mean/p95/p99). At the same time, the scope was too
broad, (negatively) affecting SQL timings in various other places:
https://gitlab.com/gitlab-com/infrastructure/issues/3772
With this commit, the snippets dashboard stays usuable as we generally
don't run into statement timeouts. In contrast to the earlier change in
!17088, the scope of the change is limited to `SnippetsFinder` only,
thus not affecting other places.
|
|
These changes were introduced in MR
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/17088. In
https://gitlab.com/gitlab-com/infrastructure/issues/3772 we discovered
these changes lead to a pretty drastic increase in SQL response timings.
We'll revert these changes so we can work on a better solution in the
mean time without GitLab.com (or other installations) experiecing
reduced performance in the mean time.
|
|
Add source and target branch filters to merge requests API
Closes #42492
See merge request gitlab-org/gitlab-ce!17355
|
|
|
|
service
|
|
Improve performance of searching for and auto completing of users
See merge request gitlab-org/gitlab-ce!17158
|
|
|
|
The frontend code doesn't use this so there's no practical point in
supporting this. We also hardcode the limit to 20 so users can no longer
request their own limit, which could overload the database (depending on
any upper bounds perhaps enforced by Kaminari).
|
|
We can instead just use a UNION. This removes the need for plucking
hundreds if not thousands of IDs into memory when a project has many
members.
|
|
|
|
Refactor IssuableFinder to extract model-specific logic
See merge request gitlab-org/gitlab-ce!17236
|
|
Simplify database queries in MembersFinder and improve performance for Projects::ProjectMembersController#index
Closes #41461
See merge request gitlab-org/gitlab-ce!17190
|
|
|
|
By extracting a new `filter_items` method, we can override that in the
IssuesFinder and MergeRequestsFinder separately, so we don't need checks that
the model is the correct one, because we can just use the class we're in to know
that.
We can do the same for the VALID_PARAMS constant, by making it a class method.
|
|
This was the default behavior, because all members with `user_id` set to
`null` were excluded.
|
|
For each member being rendered on
Projects::ProjectMembersController#index, there was a query to the users
table to retrieve the corresponding user:
```
SELECT "users".* FROM "users" WHERE "users"."id" = ? LIMIT 1
```
|
|
Realized window functions are not available in older MySQL versions
either.
Falling back to DISTINCT ON for postgresql and a convoluted translation
for MySQL.
|
|
|
|
Closes #41461.
|
|
Immediately using #from here requires a lot of changes in
other finders (e.g. IssuableFinder, TodosFinder). In all places where we
use #merge, this goes completely the wrong way when passed in a relation
that was built with `#from(...)`: The original query's FROM part gets
completely replaced.
This avoids changing all other places and focuses on improving
SnippetFinder with the downside of two (small) codepaths to do the same
thing.
|
|
|
|
|
|
|
|
Rather radical but avoids n+1 queries in the rather common case we want
to include information about the author.
|
|
'security-10-4-25223-snippets-finder-doesnt-obey-feature-visibility' into 'security-10-4'
[Port for security-10-4]: Makes SnippetFinder ensure feature visibility
|
|
Closes #40755.
|
|
|
|
Search query is especially slow if a user searches a generic string
which matches many records, in such case search can take tens of
seconds or time out. To speed up the search query, we search only for
first 1000 records, if there is >1000 matching records we just display
"1000+" instead of precise total count supposing that with such amount
the exact count is not so important for the user.
Because for issues even limited search was not fast enough, 2-phase
approach is used for issues: first we use simpler/faster query to get
all public issues, if this exceeds the limit, we just return the limit.
If the amount of matching results is lower than limit, we re-run more
complex search query (which includes also confidential issues).
Re-running the complex query should be fast enough in such case because the
amount of matching issues is lower than limit.
Because exact total_count is now limited, this patch also switches to
to "prev/next" pagination.
Related #40540
|
|
Otherwise we'd only preload the ancestors that would fit the
page. That way, when a search result was on the first page, but the
ancestor didn't fit the page anymore. We would not have the preloaded
ancestor when rendering the hierarchy.
|
|
When a project is shared with a group, it should not be included as a
descendant on the group dashboard.
|
|
Remove unnecessary query from labels dropdown
Closes #37143
See merge request gitlab-org/gitlab-ce!16520
|
|
|
|
Remove order param from the MilestoneFinder
See merge request gitlab/gitlabhq!2259
(cherry picked from commit 14408042e78f2ebc2644f956621b461dbfa3d36d)
155881e7 Remove order param from the MilestoneFinder
|
|
|
|
Improve filtering issues by label performance
Closes #40500 and #37143
See merge request gitlab-org/gitlab-ce!16136
|