<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=340825) </details> <!--IssueSummary end--> The following discussion from !67509 should be addressed: - [ ] @mkaeppler started a [discussion](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67509#note_675542762): (+4 comments) > Could you elaborate on this, i.e. inefficient how? Is this in reference to fetching all objects just to count them? Do we expect this to become a problem in production? > > Let's create a follow-up issue as well and link to it here, or it's unlikely anyone will actually replace it. > > A few questions about the implementation overall: > > * Why are caching the `tree` only when counting the total, when in `execute` we fetch it again anyway? Can we fetch-and-cache once, then count the item total? > * Why are we fetching this into redis? I assume the `total` is rendered out together with the current page. Can we cache this in-process instead? > * If we decide to use Redis, can we estimate how this will contribute to Redis memory growth over time?