| Documentation PostgreSQL 7.4.29 | ||||
|---|---|---|---|---|
| Précédent | Arrière rapide | Chapitre 13. Conseils sur les performances | Avance rapide | Suivant |
Vous pourriez avoir besoin de réaliser un grand nombre d'insertions pour remplir une base de données au tout début. Voici quelques conseils et techniques pour vous assurer de réaliser cela de la façon la plus efficace.
Désactivez la validation automatique et faites une seule validation à la fin. (En SQL, ceci signifie de lancer BEGIN au début et COMMIT à la fin. Quelques bibliothèques client pourraient le faire derrière votre dos auquel cas vous devez vous assurer que la bibliothèque le fait quand vous le voulez.) Si vous permettez à chaque insertion d'être validée séparément, PostgreSQL fait un gros travail pour chaque ligne ajoutée. Un bénéfice supplémentaire de réaliser toutes insertions dans une transaction est que si l'insertion d'une ligne échoue alors les lignes insérées jusqu'à maintenant seront annulées. Vous ne serez donc pas bloqué avec des données partiellement chargées.
Utilisez COPY FROM STDIN pour charger toutes les lignes avec une seule commande plutôt que d'utiliser une série de commandes INSERT. Ceci réduit de beaucoup la partie d'analyse, de planification, etc. Si vous le faites, il n'est plus nécessaire de désactiver l'autocommit car il ne s'agit que d'une commande.
Si vous chargez une table tout juste créée, la façon la plus rapide est de créer la table, de charger en lot les données de cette table en utilisant COPY, puis de créer tous les index nécessaires pour la table. Créer un index sur des données déjà existantes est plus rapide que de mettre à jour de façon incrémentale à chaque ligne ajoutée.
Si vous augmentez une table existante, vous pouvez supprimer les index, charger la table, puis recréer l'index. Bien sûr, les performances de la base de données pour les autres utilisateurs pourraient être sévèrement affectées tout le temps où l'index sera manquant. Vous devez aussi y penser à deux fois avant de supprimer des index uniques car la vérification d'erreur apportée par la contrainte unique sera perdue tout le temps où l'index est manquant.
Augmentez temporairement la variable sort_mem lors de la restauration de grosses quantités de données peut amener une amélioration des performances. Ceci est dû au fait qu'un index B-tree est créé à partir de rien, le contenu déjà existant de la table a besoin d'être trié. Permettre au tri merge d'utiliser plus de pages du tampon signifie que moins de passes merge seront requises.
C'est une bonne idée de lancer ANALYZE ou VACUUM ANALYZE à chaque fois que vous avez ajouté ou modifié beaucoup de données, ceci incluant le moment où vous avez rempli la table de données la première fois. Ceci vous assurez que le planificateur dispose de statistiques à jour pour la table. Sans statistiques ou avec des statistiques obsolètes, le planificateur pourrait faire de mauvais choix de plans de requêtes, amenant de mauvaises performances sur les requêtes utilisant votre table.
| Précédent | Sommaire | Suivant |
| Contrôler le planificateur avec des clauses JOIN explicites | Niveau supérieur | Administration du serveur |