Yop,
 
On est en train de tuner une base postgresql pour améliorer les perfs (genre une query qui tourne en 120 sec en renvoyant 4 résultats, je fais un index sur une table pouf 0.1 sec pour la meme query )
 
J'aimerai avoir l'avis des experts pour déterminer quels outils on pourrait utiliser pour monitorer la base et déterminer les indexs à créer.
 
Postgres 7.3.4 avec un JBoss derrière (J2EE)
 
On va déjà utiliser le vacuum toute les nuits mais bon je suppose qu'il y a moyen de faire mieux
 

si tu peux utiliser la 7.4, ils ont implémenté un auto vacuum qui a l'air pas mal sur papier (je ne peux malheureusement pas la tester sur OSX 10.2 )

 
ce n'est pas prévu pour l'instant et je préfère rester en 7.3 pour ne pas introduire des problèmes potentiels en plus. A la base c'est plutot un outil qui scanne les requetes les plus fréquentes et sur base de ca on peut analyser le résultat nous meme.  
 
Je n'ai pas besoin d'un outil qui me sors les indexs à créer ou qui les crée pour moi

Connais pas d'outils pour faire çà.
 
Dans mon appli PHP, l'execution des requêtes (Postgres et Oracle) est confiée à une classe.
La méthode runSql() calcule le temps d'exécution et log le tout dans une table mouchard.
 
Il suffit ensuite de regarder dans le mouchard les requêtes qui rament

sinon, tu peux toujours utiliser une fichier de log pour avoir toutes les commandes exécutées et faire des tris dessus.

 
oui c'est ce que je m'appretai à faire

il n'y aura pas grand chose à modifier dans ma classe pour faire ça
 
sinon mon approche est de déterminer quelles sont les requêtes les plus souvent utilisées, de voir si je peux formuler les requêtes autrement pour améliorer les perfs, sinon ajouter bêtement une clé comme dit DarkLord en exemple.
 
Mais bon, une clé en plus peut prendre plus ou moins de place en fonction du champ (je dis ça parce que j'ai dû me résoudre à poser une clé sur un champ varchar dans une base à moi, 1.2 millions de rows, parce  qu'il est quasi toujours dans la condition de recherche, mais le gain est là: 4x plus rapide)

est ce dangereux d'ajouter trop d'indexes?

bah c'est comme pour tout, trop de ... tue le ...
 
D'une part, comme l'a signalé Drasche, ca peut prendre une place supplémentaire considérable, de l'autre, si tu mets des indexes dans tous les sens, le SGDB ne va plus savoir faire des organisation efficaces ou déterminer lequel prendre pour faire une requète.

le terme dangereux ne me paraît pas approprié, disons plutôt "lourd", pour rejoindre les arguments de Gizmo
 
Tu peux sans aucun problème avoir des indexes qui prennent plus de place que la table elle-même (ok c'est bourrin ). Reste à voir si le SGBD va apprécier, et si c'est pertinent. Perso je l'ai fait (par souci de recherche et d'expérimentation hein, par pour de la prod ) sur une table qui n'existe que pour la consultation, on n'ajoute jamais rien dedans (disons que c'est un dictionnaire de données qui vient du client et qui m'est très utile quand je cherche de l'info business)