mirror of
https://github.com/django/django.git
synced 2025-04-08 15:36:47 +00:00
[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
This commit is contained in:
parent
e17e19cfa4
commit
8d196e6fea
@ -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()``
|
||||
------------------------
|
||||
|
Loading…
x
Reference in New Issue
Block a user