Forums PostgreSQL.fr

Merci beaucoup pour votre réactivité.
Je n'avais pas grand espoir mais je tentais ma chance ! J'ai malheureusement les même craintes concernant l'espoir de voir l'extension ajoutée...

Tests réalisés.

En effet cela fonctionne parfaitement de cette manière, les vacuum sont acceptés.

Merci encore pour l'assistance.

Voici la commande type et le message renvoyé :

UPDATE cad_2016.edi_parc SET code_insee = (SUBSTRING(edi_parc.codcomm FROM 1 FOR 2) || SUBSTRING(edi_parc.codcomm FROM 4 FOR 6));
VACUUM FULL VERBOSE ANALYZE cad_2016.edi_parc;

ERREUR:  VACUUM ne peut pas être exécuté à partir d'une fonction ou d'une chaîne
contenant plusieurs commandes
********** Erreur **********

ERREUR: VACUUM ne peut pas être exécuté à partir d'une fonction ou d'une chaîne
contenant plusieurs commandes
État SQL :25001

Le tout réalisé au sein de pgAdmin

Ok, merci pour ce retour ultra rapide !

Je ne sais pas écrire le code en PLpgsql, je ne suis pas informaticien de formation.

J'espérais que via une requête sur les tables ou sur les tables de statistiques il était possible de remonter ce genre d'information sans que ce ne soit trop compliqué.
En effet, quand on fait un clic droit sur un dossier "Tables" d'un schéma depuis pgAdmin et que l'on demande un "rapport des statistiques" cela nous remonte un tableau avec toutes les tables et notamment un champ "lignes vivantes" qui correspond bien au nombre de ligne des tables.

Au pire je peux me passer les schémas 1 à 1... y'en a 70.

Merci quand même !

Super, merci beaucoup !!!

Merci beaucoup pour la réponse je teste ça de suite.

Cordialement

Bonjour,

Alors, en effet le "BOM" est la source de la première erreur (« I »eUPDATE »). Et celle-ci venait bien de l'enregistrement via pgAdmin.
Et, parce que je pense que ça ne coûte rien d'être rigoureux dans ses requêtes, j'ai encadré chacune de mes requêtes d'un BEGIN - COMMIT. Depuis, tout tourne sans erreur !!! Super.

Résultat des courses et de tous vos précieux conseils :
- l'optimisation de la configuration de la base de données.
- l'optimisation du comportement des vacuums sur les tables éditées
- le passage en psql et les BEGIN/COMMIT
...ont énormément amélioré mes mises à jours. Une requête chaînée qui pouvait tourner pendant des jours... est traitée en quelques heures !!! Un grand merci à vous !!!

J'abuse peut-être, mais je vais quand même poser une dernière question sur le comportement actuel de ma requête psql (chaîne de mises à jours d'une même table).
D'après ce que j'observe via l'évolution de la fenêtre psql et le moniteur d'activité de pgAdmin :

BEGIN => début de la première transaction
Requête 1 => réalisation de la requête 1
COMMIT => fin de la transaction => initiation d'un vacuum automatique
BEGIN => début de la seconde transaction, alors que le vacuum est en train de se réaliser
Requête 2 => réalisation de la requête 2 en parallèle du vacuum
COMMIT...etc.

J'ai donc l'impression qu'à partir de la requête 2 celle-ci se réalise, au début, frontalement avec le vacuum (les deux sont visibles dans le moniteur d'activité de pgAdmin) et jusqu'à ce que celui-ci se finisse... ce qui fait sérieusement chuter les performance de mise à jour.
Le vacuum est nécessaire car sinon, au fur et à mesure des requêtes qui s'enchaînent, les performance s'effondrent.
Y-a-t-il un moyen de rendre le vacuum "exclusif" sans mettre à mal l'enchaînement des BEGIN suivants ?

Bonjour,

J'ai donc mené de nombreux tests pour optimiser et essayer de mieux comprendre le fonctionnement de postgrès à l'aide de tous vos conseils.

Requête utilisée pour les tests :

UPDATE cad_2015.edi_parc_uf
  SET age_prop_dest_av_imp_2015 = 2015 - dat_nais_prop_dest_av_imp
WHERE dat_nais_prop_dest_av_imp IS NOT NULL
  AND dat_nais_prop_dest_av_imp <> 0
;
UPDATE cad_2015.edi_parc_uf
SET type_prop = 'NR'
;
UPDATE cad_2015.edi_parc_uf
  SET type_prop = edi_parc.type_prop
FROM 
  cad_2015.edi_parc
WHERE 
  edi_parc.id_uf = edi_parc_uf.id_centr
;
UPDATE cad_2015.edi_parc_uf
SET nom_prop_desti_av_imp = 'NR'
;
UPDATE cad_2015.edi_parc_uf
  SET nom_prop_desti_av_imp = edi_parc.nom_prop_desti_av_imp
FROM 
  cad_2015.edi_parc
WHERE 
  edi_parc.id_uf = edi_parc_uf.id_centr
;

1) Tout manuel
J'ai donc commencé par refuser les autovacuum sur la table à mette à jour

ALTER TABLE cad_2015.edi_parc_uf SET (
  autovacuum_enabled = FALSE;

J'ai ensuite exécuté mes différentes requêtes unes à unes en les sélectionnant dans pgAdmin. Après chaque exécution j'ai lancé un vacuum analyze. Les résultats sont très bons et chaque requête prend de 10 à 35 minutes pour se réaliser, en 1h30 tout est fait. (personnellement ça me convient très bien en termes de performances, mais pas à l'usage, de nombreuses requêtes de ce type à lancer).

2) Tout automatisé - test 1
Même configuration que précédemment, sauf que j'ai lancé toutes les requêtes d'un coup. Là c'est a nouveau sans fin... j'ai fini par stopper la requête au bout de plusieurs heures. Les performances de postgrès s'effondrent. Aucun vacuum pour autant de requêtes enchaînées sur cette même table n'est vraiment pas une bonne idée.

relname	    n_tup_upd	n_live_tup	   last_autoanalyze	last_autovacuum	autovacuum_count	autoanalyze_count
edi_parc_uf   7035669	0			                                            0	                        0

3) Tout automatisé - test 2 (vacuums peu fréquents)
Cette fois-ci test de paramétrage des vacuums de la table :

ALTER TABLE cad_2015.edi_parc_uf SET (
  autovacuum_enabled = TRUE,
  autovacuum_vacuum_scale_factor = 1,
  autovacuum_analyze_scale_factor = 1,
  autovacuum_vacuum_threshold = 3000000,
  autovacuum_analyze_threshold = 3000000
);

Résultats identiques au point 2), mauvaise idée également.
J'en ai relancé un autre avec des valeurs un peu moins élevées mais sans plus de succès. Requête stoppée.
Pour info :

relname	    n_tup_upd	n_live_tup  	last_autoanalyze	                last_autovacuum	                    autovacuum_count       autoanalyze_count
edi_parc_uf   11092034      3002889	      2016-02-12 11:56:03.3+01         2016-02-12 11:47:51.423+01                2                    1

4) Tout automatisé - test 3 (vacuums fréquents)

ALTER TABLE cad_2015.edi_parc_uf SET (
  autovacuum_enabled = TRUE,
  autovacuum_vacuum_scale_factor = 0.01,
  autovacuum_analyze_scale_factor = 0.01,
  autovacuum_vacuum_threshold = 20000,
  autovacuum_analyze_threshold = 20000
);

Résultats identiques au point 2), la requête tourne depuis plus de 3 heures...

J'ai comme l'impression que cet enchaînement de requêtes, tant qu'il ne s'est pas intégralement réalisé :
  - verrouille la tables,
  - que les autovacuum ne peuvent s'effectuer qu'après libération de ces vérous
  - et que, donc, on se retrouve dans la même situation que pour le 2) ??? 

Dans l'absolu j'aurais pu insérer des vacuums dans mon fichier de requêtes pour qu'elles se réalisent comment dans mon cas 1) mais les vacuum ne sont pas tolérés dans cette configuration... à moins que je ne m'y prenne pas correctement.

Comment faites-vous pour mettre à jour de grosses bases de données, sur de nombreux champs ? Comme moi avec mes requêtes enchaînées... ou bien totalement différemment ?