Received: by 10.43.0.65 with SMTP id nl1mr16819568icb.23.1352925811337;
        Wed, 14 Nov 2012 12:43:31 -0800 (PST)
X-BeenThere: django-users@googlegroups.com
Received: by 10.50.188.166 with SMTP id gb6ls26875igc.27.canary; Wed, 14 Nov
 2012 12:42:56 -0800 (PST)
Received: by 10.66.81.200 with SMTP id c8mr1299617pay.1.1352925776475;
        Wed, 14 Nov 2012 12:42:56 -0800 (PST)
Received: by 10.66.81.200 with SMTP id c8mr1299616pay.1.1352925776465;
        Wed, 14 Nov 2012 12:42:56 -0800 (PST)
Return-Path: <jav...@guerrag.com>
Received: from mail-da0-f52.google.com (mail-da0-f52.google.com [209.85.210.52])
        by gmr-mx.google.com with ESMTPS id h8si2927844pav.0.2012.11.14.12.42.56
        (version=TLSv1/SSLv3 cipher=OTHER);
        Wed, 14 Nov 2012 12:42:56 -0800 (PST)
Received-SPF: pass (google.com: domain of jav...@guerrag.com designates 209.85.210.52 as permitted sender) client-ip=209.85.210.52;
Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jav...@guerrag.com designates 209.85.210.52 as permitted sender) smtp.mail=jav...@guerrag.com
Received: by mail-da0-f52.google.com with SMTP id f10so406889dak.39
        for <django-users@googlegroups.com>; Wed, 14 Nov 2012 12:42:56 -0800 (PST)
        d=google.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:x-gm-message-state;
        bh=ZOePxE/2TEQF6symbN+HpNqfXyoqX0W7EXtzBzWEqGE=;
        b=Ho5NTptboDWLi75OYJJozSm4e7+MbuwW0zw5SApRzyecmE/6aBMvmraBysd0BxTbSM
         mePNKs3ClyVIchv+vPDa38T3MTmL1I4CV4hJiDVT6Q/4Oz9OS8DzA3rSV2cyZRBmPjEt
         67uQyew8nU+CghfLBlYIU9eSIEdwwPJ8oPBwAz2eloUJtgVkhW05nbzJnWay5ayRBA6Z
         9Tqm5nTdalrpRZEUV9Pa2FmYuLbgzL9aQTd/ueRiqmNphondVMdW5wGLwOpVaAMbFGOV
         rT4uCQuCR2P/stBm6sqYRGbcpMHUqiBycLI8xfcuqtD7r4aSiYknI9cLvDniQDMKe/2R
         xS1w==
MIME-Version: 1.0
Received: by 10.68.197.101 with SMTP id it5mr1289874pbc.91.1352925776069; Wed,
 14 Nov 2012 12:42:56 -0800 (PST)
Received: by 10.66.165.102 with HTTP; Wed, 14 Nov 2012 12:42:55 -0800 (PST)
In-Reply-To: <b483e8c6-8597-45bc-8e64-b46338952430@googlegroups.com>
References: <b483e8c6-8597-45bc-8e64-b46338952430@googlegroups.com>
Date: Wed, 14 Nov 2012 15:42:55 -0500
Message-ID: <CAFkDaoTF52uCpjpWiA1F=Q=7qY++b6mt0w7YH2CDt4v7a71...@mail.gmail.com>
Subject: Re: index_together...shouldn't indexes be created AFTER populating
 the table?
From: Javier Guerra Giraldez <jav...@guerrag.com>
To: django-users@googlegroups.com
Content-Type: text/plain; charset=UTF-8
X-Gm-Message-State: ALoCoQmc0loOQD9+yW6LBB87XfTyal2Dn+1RNjc6F9dzsg6D7HQGJfvvX3tkEK91kFlCscE7JWDi

On Wed, Nov 14, 2012 at 3:14 PM, Chris Pagnutti
<chris.pagnu...@gmail.com> wrote:
> The new index_together feature is great, but I think it's best to create an
> index on a table AFTER the table is filled, and assuming there won't be many
> new inserts.

AFAIK, this is an optimization advice applicable only for mostly-static tables.

> But in django, syncdb creates the index at the same time the
> table is created, and of course, the table is initially empty.  How does
> django deal with this?

nothing to deal with, this is normal behaviour in all SQL-based databases.

> Does it know to drop the index before inserting new
> records and re-create the index afterwards?

hell, no!, that would be hideously inefficient!

what could be workable is to do that only on really big batch inserts,
only if the indexes don't carry a restriction (like UNIQUE indexes),
and really part of an off-line operation, not in the normal HTTP
request processing.

-- 
Javier