Ticket #14767: db-optimize-fixes.diff

File db-optimize-fixes.diff, 4.4 KB (added by Adam Vandenberg, 8 years ago)
  • docs/topics/db/optimization.txt

    diff --git a/docs/topics/db/optimization.txt b/docs/topics/db/optimization.txt
    index 7449d63..96d1239 100644
    a b Profile first 
    1313As general programming practice, this goes without saying. Find out :ref:`what
    1414queries you are doing and what they are costing you
    1515<faq-see-raw-sql-queries>`. You may also want to use an external project like
    16 'django-debug-toolbar', or a tool that monitors your database directly.
     16django-debug-toolbar_, or a tool that monitors your database directly.
    1717
    1818Remember that you may be optimizing for speed or memory or both, depending on
    1919your requirements. Sometimes optimizing for one will be detrimental to the
    readability of your code. **All** of the suggestions below come with the caveat 
    2929that in your circumstances the general principle might not apply, or might even
    3030be reversed.
    3131
     32.. _django-debug-toolbar: http://robhudson.github.com/django-debug-toolbar/
     33
    3234Use standard DB optimization techniques
    3335=======================================
    3436
    3537...including:
    3638
    3739* Indexes. This is a number one priority, *after* you have determined from
    38   profiling what indexes should be added. Use :attr:`django.db.models.Field.db_index` to add
    39   these from Django.
     40  profiling what indexes should be added. Use :attr:`django.db.models.Field.db_index`
     41  to add these from Django.
    4042
    4143* Appropriate use of field types.
    4244
    Understand cached attributes 
    6971As well as caching of the whole ``QuerySet``, there is caching of the result of
    7072attributes on ORM objects. In general, attributes that are not callable will be
    7173cached. For example, assuming the :ref:`example Weblog models
    72 <queryset-model-example>`:
     74<queryset-model-example>`::
    7375
    7476  >>> entry = Entry.objects.get(id=1)
    7577  >>> entry.blog   # Blog object is retrieved at this point
    Don't retrieve things you don't need 
    156158Use ``QuerySet.values()`` and ``values_list()``
    157159-----------------------------------------------
    158160
    159 When you just want a dict/list of values, and don't need ORM model objects, make
    160 appropriate usage of :meth:`~django.db.models.QuerySet.values()`.
    161 These can be useful for replacing model objects in template code - as long as
    162 the dicts you supply have the same attributes as those used in the template, you
    163 are fine.
     161When you just want a ``dict`` or ``list`` of values, and don't need ORM model
     162objects, make appropriate usage of
     163:meth:`~django.db.models.QuerySet.values()`. These can be useful for replacing
     164model objects in template code - as long as the dicts you supply have the same
     165attributes as those used in the template, you are fine.
    164166
    165167Use ``QuerySet.defer()`` and ``only()``
    166168---------------------------------------
    Use ``QuerySet.defer()`` and ``only()`` 
    168170Use :meth:`~django.db.models.QuerySet.defer()` and
    169171:meth:`~django.db.models.QuerySet.only()` if there are database columns you
    170172know that you won't need (or won't need in most cases) to avoid loading
    171 them. Note that if you *do* use them, the ORM will have to go and get them in a
    172 separate query, making this a pessimization if you use it inappropriately.
    173 
    174 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.
     173them. Note that if you *do* use them, the ORM will have to go and get them in
     174a separate query, making this a pessimization if you use it inappropriately.
     175
     176Also, be aware that there is some (small extra) overhead incurred inside
     177Django when constructing a model with deferred fields. Don't be too aggressive
     178in deferring fields without profiling as the database has to read most of the
     179non-text, non-VARCHAR data from the disk for a single row in the results, even
     180if it ends up only using a few columns. The ``defer()`` and ``only()`` methods
     181are most useful when you can avoid loading a lot of text data or for fields
     182that might take a lot of processing to convert back to Python. As always,
     183profile first, then optimize.
    175184
    176185Use QuerySet.count()
    177186--------------------
Back to Top