Vous n'êtes pas identifié(e).
Bonjour,
Voici mon problème j'ai une base de données avec une 50aine de table
dans ces tables j'en ai 24 qui sont identiques ou l'on dispatche des logs de sessions provenant de différents serveurs.
ces tables ont entre 700000 et 2000000 d'enregistrement.
j
Pour optimiser mes tables et mes requêtes j'ai rajouté 2 champs d'entier dans chacune des 24 tables
dans ma table actuellement j'ai deux champs texte qui me permettent de faire la jointure avec d'autre table.
Donc l'idée est de créer des clés etrangères d'entier pour optimiser les requetes.
donc pour mon update
j'ai une requete du type
udpate <table> a set champ_id_etranger_int=(select champ_id from <table2> b where a.champ_texte=b.champ_text) where champ_id_etranger_int is null and....
j'ai fait un test sur la prod sur une seule table.... aucun souci
pour pouvoir parcourir mes 24 tables je met donc en place une procédure stockée qui va updater tous mes champs dans chaque table
Le problème est que la taille de mes tables ont doublé.
je suis passée d'une base de 25 Go (environ ) a plus de 50 Go
il n 'y a pas de doublons
j'ai tenté sur une des tables de dropper mes nouvelles colonnes .... aucun changement dans la taille de ma table.
est ce la procédure stockée qui aurait pu avoir cette impact avec une sorte de cache ??
Merci d'avance à celui ou celle qui pourra m'éclairer car la c'est un mystère....
Dernière modification par kris2001fr (30/11/2010 23:55:47)
Hors ligne
Le doublage de taille de la base vient pratiquement à coup sûr des UPDATE. PostgreSQL ne met pas à jour directement la ligne mais crée une deuxième version de ligne pour chaque ligne impactée, ce qui peut augmenter la taille de chaque table qui a subi cet UPDATE. (c'est une version simplifiée de ce qui se passe mais ça se tient dans les grandes lignes)
Quant au fait que le DROP des colonnes n'a rien changé à la taille des tables, c'est normal aussi. Pour que l'opération soit la plus rapide possible, PostgreSQL ne réécrit pas les tables. Il indique juste que la colonne n'existe plus.
Questions subsidiaires : quelle version de PostgreSQL ? l'autovacuum est-il activé ?
Guillaume.
Hors ligne
Bonjour,
il y a un vaccum analyse qui est planifié chaque nuit.
Le vacuum devrait résoudre le problème? comment faire pour que ces deux versions ne soient plus qu'une??
ce matin en tout cas aucun changement dans nos tables.
et Comment faire pour que les colonnes soient réellement supprimés?
la version de postgresql est 8.3.8
Merci en tout cas pour ces précieuses informations..
Bonne journée
Hors ligne
Le vacuum ne résoudra pas le problème: il va supprimer l'ancienne version de l'enregistrement, mais la table ne retrouvera pas sa taille initiale. Cet espace sera simplement réutilisable.
Par ailleurs, étant en 8.3, vérifiez que votre FSM (les paramètres en max_fsm dans votre configuration) sont suffisants. Ce n'est certainement pas le cas, vu qu'il va y avoir 25Go d'espace libre dans cette base.
Essayez «VACUUM VERBOSE» en ligne de commande, et copiez ici les 10 dernières lignes.
Marc.
Hors ligne
est ce que un cluster ne va pas libérer la place "réutilisable" ?
je vais poser le problème pour le FSM
pour le verbose pour l'instant je peux pas le faire.
Merci pour vos réponses
Hors ligne
'CLUSTER' va récupérer la place, sur les tables que vous allez clusteriser. Par contre, cela risque d'être un peu long, et va bloquer toute modification de la table en cours de cluster pendant l'opération.
Marc.
Hors ligne
Encore une dernière question.
il vaut mieux faire un cluster ou ou une modification de type d'une colonne?
Nous n'avons pas trop le choix car il nous faut récuperer de la place ...
Hors ligne
les deux sont intéressants. La modification du type de colonne sera plus rapide en termes de performance (moins d'entrées-sorties aléatoires).
Marc.
Hors ligne
MERCI POUR TOUT!!
Hors ligne
Bonjour,
Encore une question..
Est il possible d'éviter la "duplication" de la ligne avec une option dans le update( j'ai regardé la doc rien trouvé..)
Ou est ce que c'est inévitable?
PS :le alter column a bien fonctionné .... ca m'a sauvé
Hors ligne
Non, ce n'est pas possible. La raison de cette duplication est ce qui fait tout l'intérêt de PostgreSQL.
Guillaume.
Hors ligne
