Add additional example

doc/development/merge_request_performance_guidelines.md

@@ -164,6 +164,15 @@ In a DB cluster we have many read replicas and one primary.  A classic use of sc
 
 By default queries use read-only replicas, but due to [primary sticking](https://docs.gitlab.com/ee/administration/database_load_balancing.html#primary-sticking) GitLab will stick to using the primary for a certain period of time and revert back to secondaries after they have either caught up or 30 seconds which can lead to a considerable amount of unnecessary load on the primary. In this [merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/56849) we introduced the `without_sticky_writes` block to prevent switching to the primary. This [merge request example](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/57328) provides a good use case for when queries can stick to the primary and how to prevent this by using `without_sticky_writes`.
 
+Internally, our database load balancer classifies the queries based on their main statement (`select`, `update`, `delete`, etc.). When in doubt, it redirects the queries to the primary database. Hence, there are some common cases the load balancer sends the queries to the primary unnecessarily:
+
+- Custom queries (via `exec_query`, `execute_statement`, `execute`, etc.)
+- Read-only transactions
+- In-flight connection configuration set
+- Sidekiq background jobs
+
+Worse, after the above queries are executed, GitLab will [stick to the primary](https://docs.gitlab.com/ee/administration/database_load_balancing.html#primary-sticking). In [this merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/56476), we introduced `use_replica_if_possible` block to make the inside queries prefer to use the replicas. That MR is also an example how we redirected a costly, time-consuming query to the replicas.
+
 ## Use CTEs wisely
 
 See section https://docs.gitlab.com/ee/development/iterating_tables_in_batches.html#complex-queries-on-the-relation-object for considerations on how to use CTEs.  We have found in some situations CTEs can become problematic in use (similar to the n+1 problem above).  In particular, hierarchical recursive CTE queries <example link?> are very difficult to optimize and don't scale.  We should avoid them when implementing new fatures that require any kind of hierarchical structure.