Version imprimable
Bonjour,
J'étais sous postgres 7.2 et depuis que j'ai migré sous postgres 8 toutes mes requêtes "UPDATE" rament.
La simple mise à jour d'un champs sur 200 000 enregistrement prend 1h.
(2 requetes update)
De plus, sous postgres 7 je n'avais même pas d'index pour faire que la reqête aille plus vite.
J'en ai mis sous postgres 8.
Enfin j'ai configuré le fichier de conf de postgres 8 à -> index_scan true;
Une idée du problème ?
Bonjour,
L'index accélère certes la recherche de l'enregistrement à modifier définie dans la clause WHERE, mais ralentit l'UPDATE puisque l'index est mis à jour en même temps que la base (à condition que le(s) champ(s) mis à jour soi(en)t impliqué(s) dans l'index). Cela expliquerait le ralentissement, plutôt que le passage à PostgreSQL 8...Citation:
Envoyé par julienOriano
merci ! J'aurai au moins appris quelque choses !
Mais les index impliqués dans la mise à jour de cette table ne contiennent pas les données mises à jour (1 seul champs mis à jour)
Cela ne pourrait il pas venir du Recyclage du journal de transaction !
En effet, avant l'update je fais 200 000 insert dans un block BEGIN,COMMIT
Penadant mon upadte, j'ai des Recyclage du journal de transaction «0000034A00000068»
Il y en a pas mal !
Y a til un moyen simple pour optimiser les requetes d update (conf de postgres ou autre) !
Je ne trouve rien !
Merci
Une possibilité, mais en aucun cas une garantie : utiliser une requête préparée (prepared query).
La préparation de la requête se fait avec la commande PREPARE. Par exemple :
my_plan est une chaîne arbitraire qui désigne la requête préparée. Les types de données qui suivent sont les paramètres passés à la requête, désignés dans la requête elle-même par $1 et $2.Code:PREPARE my_plan (text, int4) AS UPDATE my_table SET my_field = $1 WHERE my_id = $2;
Pour exécuter la requête n fois, il suffit d'appeler n fois EXECUTE en passant le nom de la requête préparée et les valeurs des paramètres :
La requête ayant déjà été parsée, compilée, planifiée lors du PREPARE, son exécution devrait être plus rapide que si elle avait été transmise directement au back-end. Il est quand même conseillé de faire un ANALYZE avant le PREPARE pour mettre à jour les statistiques et que la planification soit optimale.Code:EXECUTE my_plan ('my value', 12345);