[3.0.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 35396a7f243eceec42cc90725ab573a7d9ac3b4c from master

1 files changed, 6 insertions, 8 deletions

diff --git a/docs/topics/db/optimization.txt b/docs/topics/db/optimization.txt
index e0ff14e0d6..01c17571ab 100644
--- a/docs/topics/db/optimization.txt
+++ b/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
-Django when constructing a model with deferred fields. Don't be too aggressive
-in deferring fields without profiling as the database has to read most of the
-non-text, non-VARCHAR data from the disk for a single row in the results, even
-if it ends up only using a few columns. The ``defer()`` and ``only()`` methods
-are most useful when you can avoid loading a lot of text data or for fields
-that might take a lot of processing to convert back to Python. As always,
-profile first, then optimize.
+Don't be too aggressive in deferring fields without profiling as the database
+has to read most of the non-text, non-VARCHAR data from the disk for a single
+row in the results, even if it ends up only using a few columns. The
+``defer()`` and ``only()`` methods are most useful when you can avoid loading a
+lot of text data or for fields that might take a lot of processing to convert
+back to Python. As always, profile first, then optimize.
 
 Use ``QuerySet.count()``
 ------------------------