Bonjour,

Merci pour touts ces infos, les choses deviennent plus claires.
J'ai retenu l'idée de l'historisattion (excellente). Ca ma permet de comprendre un peut mieux comment "fonctionne" cette table.
J'ai fait un pg_stat_reset et programmé un cron pour collecter et stocker les stats de cette table toutes les 15 mn.

A vue de nez je pense que les 20% sont largement atteint.

+Eric.

Le stats_row_level est à true dans postgresql.conf.
Je suppose que le résultat est stocké dans pg_stat_*_tables, en tout cas ce sont les infos que j'ai utilisé pour identifier les tables à "problèmes".
Par rapport à ce que j'ai lu et compris de postgres et de sa gestion des updates/insert/delete j'ai fait une requette qui me ramène les tables les plus mouvementées.

Mais je reconnais volontier que je ne sais pas forcement bien en interpréter le résultat.

Pour l'une des tables les plus solicités j'obtiens ceci:

 relname | seq_scan | seq_tup_read | idx_scan | idx_tup_fetch | n_tup_ins | n_tup_upd | n_tup_del 
---------+----------+--------------+----------+---------------+-----------+-----------+-----------
 offre   |    10169 |   2813393725 |   554878 |     687402756 |       853 |    620862 |         0
(1 ligne)

Question bête (encore): les valeurs représentent un cumul depuis la première mise en route de postgres ?

Bonjour,

Effectivement le VACUUM toute les heures améliorement beaucoup les choses (testé sur une autre table à problème).
Question bête un VACUUM ANALYZE c'est bien l'équivalent des deux commandes séparée (VACCUM et ANALYZE) ?

+Eric.

Effectivement les perfs de nos applis web deviennent parfois désespérentes...
Une vielle version de postgres 7.4.23 sur Debian.
le vacuum analyze est passé tous les jours.
Il n' y a pas de autovacuum, je me suis laissé dire qu'il était buggé.

Pour exemple:

J'ai une table de -300 000 lignes, ~30 colonnes qui fait plus de ~1.5Go et qui doit tomber à ~Mo après un vacuum full.

+Eric.