Vous n'êtes pas identifié(e).
Pages : 1
Merci pour la réponse.
Debian 4 et installation à partir du tarball.
Effectivement ça va mieux avec libpq-dev
Bonjour,
J'essaye d'utiliser pgsnap, mais à l'exécution il me cherche un pg_config que je ne trouve nul part.
Savez-vous où je pourrais trouver ce programme ?
Mais je ne suis peut-être pas au bon endroit pour cette question...
+Eric.
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.
Bonjour,
gleu: Merci pour la précision.
+Erjo
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,
J'essaye de vérifier, via les stats, l'efficacités des indexes qui ont été créés sur des tables.
D'après ce que je comprends:
idx_scan = nombre de fois où l'indexe à été lu.
idx_tup_read = nombre de lignes lues
idx_tup_fetch = nombre ligne récupérée.
- Je ne voies pas trop la différence entre fetch et read, où dans quel cas les valeurs pourraient être différentes.
- Je me qu'un idx_scan faible ou égal à 0 ne sert pas à grand et peut/doit être supprimé.
Par contre je ne sais pas trop comment interprété ce genre de valeurs
idx_scan = 38263
idx_tup_read = 173626246
idx_tup_fetch = 173626246
En claire est-ce que cela veut dire que l'indexe est éfficace ?
+Eric.
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.
* Pour être plsu précis c'est plutôt ~100Mo par jour.
* max_fsm_pages vaut 20 000 (valeur par défaut). Je vais regarder pour auguementer.
Je suppose que cette valeur est partagée par toutes les bases, Je devrais en tenir compte, non ?
* Merci pour la doc.
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.
Merci pour la réponse (c'est rapide!).
Ca à l'air intéressant mais plus destiné aux développeurs à priori.
En fait mon objectif c'est d'optimiser des tables sur lesquelles il y a beaucoup de mouvement (UPDATE, DELETE, INSERT en masse).
J'ai remarqué que la requette VACUUM FULL sur les tables incriminées améliorait les temps de réponses de l'application.
J'ai donc imaginé de lance tous les jours un VACUUM FULL suivit d'un REINDEX.
Mais peut être peut-on faire plus subtil ?
Aurais-je intérêt à faire un ANALYZE en plus ?
Merci d'avance.
+Eric.
Bonjour,
J'ai lu que la requette CLUSTER permettait de ré-ordonner une table (c'est du moins ce que j'ai compris.).
Est-ce que ce serait l'équivalent d'un VACUUM FULL par exemple ?
Cela permet-il vraiment d'obtenir de meilleurs performance que une table ou ça n'a rien à voire ?
+Eric.
Rapide la réponse. Merci beaucoup.
J'avais survolé la doc, n'étant pas en 8.4 je ne pensais pas être concerné...
Bonjour,
En faisant un vaccum full sur une table j'ai noté la ligne suivant:
INFO: « pg_toast_4278053 » : 323 versions de ligne déplacées, 3566 pages tronquées sur 2949Je ne comprends pas trop à quoi correspond la table pg_toast et surtout pourquoi elle à été créée.
Si quelqu'un avait une idée...
NB: Je suis en version 7.4 (Oui, je sais...)
+Erjo
Pages : 1