-
Les index sont généralement inutiles pour les opérations sur 90 % de toutes les lignes. Les analyses séquentielles seront plus rapides dans les deux sens. (Des exceptions exotiques s'appliquent.)
-
Si vous devez autoriser les lectures simultanées, vous ne pouvez pas poser de verrou exclusif sur la table. Vous ne pouvez donc pas non plus supprimer d'index dans la même transaction.
-
Vous pourriez supprimez les index dans des transactions séparées pour maintenir la durée du verrouillage exclusif au minimum. Dans Postgres 9.2 ou version ultérieure, vous pouvez également utiliser DROP INDEX CONCURRENTLY , qui ne nécessite qu'un minimum de verrous. Utilisez ultérieurement
CREATE INDEX CONCURRENTLY
pour reconstruire l'index en arrière-plan - et ne prendre qu'un très bref verrou exclusif.
Si vous avez une condition stable pour identifier les 10 % (ou moins) de lignes qui restent, je suggérerais un index partiel sur ces lignes uniquement pour obtenir le meilleur pour les deux :
- Les requêtes de lecture peuvent accéder à la table rapidement (à l'aide de l'index partiel) à tout moment.
- Le gros
DELETE
ne va pas du tout modifier l'index partiel, car aucune des lignes n'est impliquée dans leDELETE
.
CREATE INDEX foo (some_id) WHERE delete_flag = FALSE;
En supposant delete_flag
est boolean
. Vous devez inclure le même prédicat dans vos requêtes (même s'il semble logiquement redondant) pour vous assurer que Postgres peut l'index partiel.