Vous n'êtes pas identifié(e).
Bonjour,
J'aurai une petite question concernant les vacuum et autre analyze lorsqu'on a une réplication de type hot standby sur des serveurs PostgreSQL 9.0 (installés via les backports Debian Squeeze).
Sur mon master j'execute un vacuum analyze ( avec une commande de type : su postgres -c "vacuumdb -U postgres -a -z" ) et je peux ensuite constater qu'il y a bien des stats qui sont calculées sur les tables de mes bases comme on peut le voir ici :
myplopDB - master=# select * from pg_stat_all_tables where relname='paloup';
-[ RECORD 1 ]----+------------------------------
relid | 37271
schemaname | public
relname | paloup
seq_scan | 16
seq_tup_read | 5537792102
idx_scan | 2858383
idx_tup_fetch | 2062859095
n_tup_ins | 346406962
n_tup_upd | 290225
n_tup_del | 0
n_tup_hot_upd | 29040
n_live_tup | 346852072
n_dead_tup | 22496
last_vacuum | 2011-04-06 00:48:17.670045+02
last_autovacuum |
last_analyze | 2011-04-06 00:50:54.966283+02
last_autoanalyze | 2011-03-23 17:03:41.917984+01Je sais qu'on ne peut pas executer ce type de vacuum sur le slave (à cause du mode recovery comme on peut le lire dans la doc), cependant j'esperai que les statistiques soient répliquées sur le slave mais ce n'est pas le cas comme on peut le constater ici :
myplopDB - slave=# select * from pg_stat_all_tables where relname='paloup';
-[ RECORD 1 ]----+-----------
relid | 37271
schemaname | public
relname | paloup
seq_scan | 13
seq_tup_read | 4501342601
idx_scan | 17652
idx_tup_fetch | 2497364528
n_tup_ins | 0
n_tup_upd | 0
n_tup_del | 0
n_tup_hot_upd | 0
n_live_tup | 0
n_dead_tup | 0
last_vacuum |
last_autovacuum |
last_analyze |
last_autoanalyze |Je pense que je suis passé à côté de qqchose mais je trouve peu de retours sur le sujet
Je me sers de mon slave pour toutes mes lectures et donc fatalement sans les stats je perds beaucoup en perf surtout sur des requêtes compliquées...
Y a t'il un moyen de calculer ces stats sur les slaves ?
Si vous avez des pistes je suis preneur ! 
Merci d'avance,
/Erwan
Hors ligne
Ces statistiques ne sont pas utilisées par l'optimiseur. Ce sont des statistiques d'accès, et elles ne sont effectivement pas dans une «vraie» table journalisée. Elles ne sont donc pas répliquées.
Les statistiques utilisées par l'optimiseur sont dans pg_statistics (ou la vue pg_stats, qui est plus lisible). Celle-là est une vraie table, et je doute qu'elle ne soit pas répliquée.
Marc.
Hors ligne
Bonjour Marc,
Merci pour ce retour rapide !
Effectivement tu as raison le contenu de pg_stats est bien repliqué du coup je me faisais du souci pour rien
J'ai plus qu'à chercher le pourquoi j'ai l'impression que mes perfs ne sont pas au top alors !
encore merci !
Hors ligne