p31829507
/
django
mirror of https://github.com/django/django.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

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.
This commit is contained in:
Simon Charette 2019-10-14 06:51:07 -04:00 committed by Mariusz Felisiak
parent 06d34aab7c
commit 35396a7f24
1 changed files with 6 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
docs/topics/db/optimization.txt
View File

@ -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()``
------------------------