[2.2.x] Refs #26207 -- Removed obsolete note about slow constructing a model with deferred fields.

This is not true since 7f51876 removed the necessity of creating
proxy model classes at runtime for each deferred field sets.
Backport of 35396a7f24 from master

docs/topics/db/optimization.txt

@@ -233,14 +233,12 @@ you know that you won't need (or won't need in most cases) to avoid loading
 them. Note that if you *do* use them, the ORM will have to go and get them in
 a separate query, making this a pessimization if you use it inappropriately.
 
-Also, be aware that there is some (small extra) overhead incurred inside
+Don't be too aggressive in deferring fields without profiling as the database
-Django when constructing a model with deferred fields. Don't be too aggressive
+has to read most of the non-text, non-VARCHAR data from the disk for a single
-in deferring fields without profiling as the database has to read most of the
+row in the results, even if it ends up only using a few columns. The
-non-text, non-VARCHAR data from the disk for a single row in the results, even
+``defer()`` and ``only()`` methods are most useful when you can avoid loading a
-if it ends up only using a few columns. The ``defer()`` and ``only()`` methods
+lot of text data or for fields that might take a lot of processing to convert
-are most useful when you can avoid loading a lot of text data or for fields
+back to Python. As always, profile first, then optimize.
-that might take a lot of processing to convert back to Python. As always,
-profile first, then optimize.
 
 Use ``QuerySet.count()``
 ------------------------