Django créé pour tous les champs varchar et text deux index par défaut : un pour les comparaisons exactes et un pour permettre de faire des requêtes SQL avec des LIKE. La plupart du temps ces requêtes là ne nous intéressent pas.
En spécifiant explicitement les index à créer on peut éviter ce créer ces index en trop (qui se terminent par _like.
Je fais un test sur la colonne status.
Le SQL généré par cette migration est le suivant :
-- Alter field status on building
--
DROP INDEX IF EXISTS "batid_building_status_483845ab";
DROP INDEX IF EXISTS "batid_building_status_483845ab_like";
--
-- Alter field status on buildinghistoryonly
--
DROP INDEX IF EXISTS "batid_building_history_status_648b7c4d";
DROP INDEX IF EXISTS "batid_building_history_status_648b7c4d_like";
--
-- Concurrently create index bdg_status_idx on field(s) status of model building
--
CREATE INDEX CONCURRENTLY "bdg_status_idx" ON "batid_building" ("status");
--
-- Concurrently create index bdg_history_status_idx on field(s) status of model buildinghistoryonly
--
CREATE INDEX CONCURRENTLY "bdg_history_status_idx" ON "batid_building_history" ("status");
Je découvre qu'il est aussi possible de faire créer des index CONCURRENTLY depuis Django, en modifiant le fichier de migration à la main.
Mon savoir vient de cet article qui est intéressant.
Django créé pour tous les champs varchar et text deux index par défaut : un pour les comparaisons exactes et un pour permettre de faire des requêtes SQL avec des
LIKE. La plupart du temps ces requêtes là ne nous intéressent pas. En spécifiant explicitement les index à créer on peut éviter ce créer ces index en trop (qui se terminent par_like.Je fais un test sur la colonne status. Le SQL généré par cette migration est le suivant :
Je découvre qu'il est aussi possible de faire créer des index CONCURRENTLY depuis Django, en modifiant le fichier de migration à la main.
Mon savoir vient de cet article qui est intéressant.