Following the discussion in: * https://gitlab.com/gitlab-org/gitlab/-/merge_requests/31095#note_338858755 * https://gitlab.com/gitlab-org/gitlab/-/issues/216835 In https://gitlab.com/gitlab-org/gitlab/-/issues/217103 we introduced a way to detect the number of DB cached calls in the scope of the request and sidekiq worker. > The cached queries help with reducing DB load, but they still: > > * consume memory > * require as to re-instantiate each AR object > * require as to re-instantiate each relation of the object > * makes us spend additional CPU-cycles to look into a list of cached queries. > > We should treat the `CACHE` the same as `N+1` queries. > They are cheaper, but they are not cheap at all from \~memory perspective. Now that we have the [means](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/32131) to detect the amount of `CACHE` queries in requests/workers, we should: 1. Provide metrics that would help us to detect the potential N+1 `CACHED` SQL calls 1. Document why N+1 `Cached` queries are considered bad from \~memory perspective, and update documentation (https://docs.gitlab.com/ee/development/merge_request_performance_guidelines.html#query-counts. 1. Update documentation for [QueryRecorder](https://docs.gitlab.com/ee/development/query_recorder.html), add examples how to write tests for N+1 cached queries like we did for: https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/lib/banzai/filter/label_reference_filter_spec.rb#L34-45 1. Reduce several cached calls, improve those endpoints (if possible), measure the performance improvements, add specs using QueryRecorder, and use them as an example for other teams. 1. Provide guidelines, if not already provided by previous bullet points, enabling other teams to be able to detect cached sql calls, and fix them.