Django/django
11
0
Fork 0
Code Pull Requests Projects Releases Activity

[1.2.X] Fixed #14767 -- Reflowed paragraphs and cleaned up some markup/links in the topics/db/optimizations docs. Thanks to adamv for the report and patch.

Browse Source 
Backport of [14690] from trunk.

git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.2.X@14691 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Gabriel Hurley 2010-11-24 11:53:04 +00:00
parent 1c451c0f39
commit 857131685a
1 changed files with 14 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -13,7 +13,7 @@ Profile first
As general programming practice, this goes without saying. Find out :ref:`what
queries you are doing and what they are costing you
<faq-see-raw-sql-queries>`. You may also want to use an external project like
'django-debug-toolbar', or a tool that monitors your database directly.
django-debug-toolbar_, or a tool that monitors your database directly.
Remember that you may be optimizing for speed or memory or both, depending on
your requirements. Sometimes optimizing for one will be detrimental to the
@ -29,14 +29,16 @@ readability of your code. **All** of the suggestions below come with the caveat
that in your circumstances the general principle might not apply, or might even
be reversed.
.. _django-debug-toolbar: http://robhudson.github.com/django-debug-toolbar/
Use standard DB optimization techniques
=======================================
...including:
* Indexes. This is a number one priority, *after* you have determined from
profiling what indexes should be added. Use :attr:`django.db.models.Field.db_index` to add
these from Django.
profiling what indexes should be added. Use
:attr:`django.db.models.Field.db_index` to add these from Django.
* Appropriate use of field types.
@ -69,7 +71,7 @@ Understand cached attributes
As well as caching of the whole ``QuerySet``, there is caching of the result of
attributes on ORM objects. In general, attributes that are not callable will be
cached. For example, assuming the :ref:`example Weblog models
<queryset-model-example>`:
<queryset-model-example>`::
>>> entry = Entry.objects.get(id=1)
>>> entry.blog # Blog object is retrieved at this point
@ -156,11 +158,11 @@ Don't retrieve things you don't need
Use ``QuerySet.values()`` and ``values_list()``
-----------------------------------------------
When you just want a dict/list of values, and don't need ORM model objects, make
appropriate usage of :meth:`~django.db.models.QuerySet.values()`.
When you just want a ``dict`` or ``list`` of values, and don't need ORM model
objects, make appropriate usage of :meth:`~django.db.models.QuerySet.values()`.
These can be useful for replacing model objects in template code - as long as
the dicts you supply have the same attributes as those used in the template, you
are fine.
the dicts you supply have the same attributes as those used in the template,
you are fine.
Use ``QuerySet.defer()`` and ``only()``
---------------------------------------
@ -238,10 +240,10 @@ individual, use a bulk SQL UPDATE statement, via :ref:`QuerySet.update()
<topics-db-queries-update>`. Similarly, do :ref:`bulk deletes
<topics-db-queries-delete>` where possible.
Note, however, that these bulk update methods cannot call the ``save()`` or ``delete()``
methods of individual instances, which means that any custom behaviour you have
added for these methods will not be executed, including anything driven from the
normal database object :doc:`signals </ref/signals>`.
Note, however, that these bulk update methods cannot call the ``save()`` or
``delete()`` methods of individual instances, which means that any custom
behaviour you have added for these methods will not be executed, including
anything driven from the normal database object :doc:`signals </ref/signals>`.
Use foreign key values directly
-------------------------------