From 35396a7f243eceec42cc90725ab573a7d9ac3b4c Mon Sep 17 00:00:00 2001 From: Simon Charette Date: Mon, 14 Oct 2019 06:51:07 -0400 Subject: [PATCH] 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. --- docs/topics/db/optimization.txt | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/docs/topics/db/optimization.txt b/docs/topics/db/optimization.txt index 9de7598413..87a083e0f8 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()`` ------------------------