Update based on feedback

doc/development/merge_request_performance_guidelines.md

@@ -158,15 +158,15 @@ objects_to_update.update_all(some_field: some_value)
 This uses ActiveRecord's `update_all` method to update all rows in a single
 query. This in turn makes it much harder for this code to overload a database.
 
-## Consider using read replicas for read access
+## Use read replicas when posible
 
-In a DB cluster we have many read replicas and one primary.  A classic use of scaling the DB is to have read only actions be performed the replicas.  This allows for the replics to grow as the pressure on the DB grows.
+In a DB cluster we have many read replicas and one primary.  A classic use of scaling the DB is to have read only actions be performed the replicas.  We use [load balancing](https://docs.gitlab.com/ee/administration/database_load_balancing.html)) to distribute this load.  This allows for the replics to grow as the pressure on the DB grows.
 
 < insert example here>
 
-## Use CTEs sparingly
+## Use CTEs wisely
 
-We have found in some situations CTEs can become problematic in use (similar to the n+1 problem above).  As such if you need to use them you should make sure you are using them correctly.  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.  
+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.  
 
 <insert example/reference/fix up here>