mirrors/django
mirrors/django
0
0
Fork 0
mirror of https://github.com/django/django.git synced 2024-12-01 15:42:04 +01:00
Code Issues Releases Wiki Activity

The optimization docs were a little too enthusiastic in recommending

Browse Source 
defer() and only() usage. Disk access patterns affect when this is a
good idea, so this patch adds a note about the trade-offs.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@13820 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Malcolm Tredinnick 2010-09-13 05:08:17 +00:00
parent 17a79d5033
commit 767cf13d76
1 changed files with 2 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -171,6 +171,8 @@ 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.
Use QuerySet.count()
--------------------