1
0
mirror of https://github.com/django/django.git synced 2024-12-23 09:36:06 +00:00

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

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 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. 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()`` Use ``QuerySet.count()``
------------------------ ------------------------