Re: linuxfr.org dans une base postgresql ?

Pour que les perfs soient bonnes pas de secret avec postgresql ... faire un show du plan d'analyse et creer les index qui vont bien. Tu fais ça en ligne de commande, ou bien tu utilises le bel outil graphique de RedHat (pour le "show plan") ? Il faudra que j'essaie pour voir, sauf que j'ai des requêtes simples donc les index coulent de source (souvent, celui par défaut sur la clef primaires suffit). Pour ce qui est du vaccum il tourne la nuit et il prend qq heures ( 5 heures ) La vache, je comprends que ça dérange certains, en particulier quand la base doit fonctionner 24h/24 (même s'il y a un creux la nuit). Tu fais un "vacuum full" ou un simple vacuum (depuis je ne sais plus quelle version récente, il existe un vacuum qui ne bloque pas les tables, mais du coup je ne sais pas à quel point ce vacuum est efficace par rapport au "full"). Au fait, quelle version de Postgres utilises-tu ? Pour ce qui est des optims, en ajustant la share memory, les params du journal Justement, tu pourrais me donner ton fichier d'options ou ta ligne de commande (pour que je voie les paramètres du genre de ceux que tu mentionnes). J'ai remarqué qu'en augmentant la mémoire partagée on augmentait un peu les perfs, j'ai mis "-B 256" au lieu des 64 de base, mais je n'ai presque pas joué avec les paramètres (en particulier le journal). Est-ce que tu utilises l'option "-F" (do not flush) ? surtout les index qui sont sur un disque différents des tables de données Pas mal. Tu as combien de disques différents ? J'imagine que mettre le journal (WAL file) sur un disque séparé accélère bien les choses aussi. Voila j'espere que ca repond a tes questions Merci pour toutes tes informations. J'essaie de pousser à fond Postgres dans ma boîte car on utilise Oracle mais pour des besoins qui ne le justifient pas du tout à mon avis (et quand j'ai vu le prix d'une licence, j'ai sursauté). Problème, ça "rassure" un peu le client (qui au passage doit acheter une licence Oracle).