Re: comment maximiser les performances PG

[Francis Leboutte <f(dot)leboutte(at)algo(dot)be>]

Le 31/07/2007 08:46, Guillaume Lelarge écrivait :
> Bonjour,
>
> Francis Leboutte a écrit :
> > Je profite de la lecture du fil "Répones lente de PG" lu avec intérêt
> > pour poser quelques questions générales sur comment augmenter les
> > performances d'un serveur PG. Je m'apprête de fait à mettre en ligne un
> > système de recherche d'information dans des documents où les index sont
> > simplement des tables PG.
>
> Je ne suis pas sûr d'avoir compris. Vous utilisez votre propre système
> d'indexage ? en gros, vous utilisez une table comme index, ce qui fait
> que vous requêtez d'abord la table "index" puis la table ? si oui,
> pourquoi ? quel intérêt pour vous ? parce que PostgreSQL sera incapable
> d'utiliser ce faux index, donc il me semble que vous perdrez en
> performance... ou alors je n'ai rien compris, ce qui est possible de si
> bon matin :)

J'aurais dû être plus clair pour éviter la 
confusion entre les index de PG et la notion 
d'index en recherche d'information. Dans ce 
dernier cas (IR - information retrieval), on 
parle d'indexation de documents et aussi 
d'"inverted index" ou "inverted file" ou 
simplement d'index pour quelque chose qui permet 
de retrouver rapidement de l'information associée 
à un mot (terme). Cette information, c'est 
principalement la liste des documents dans 
lequels le mot est présent ("postings list"). 
Éventuellement le score du mot et les positions du mot dans le document.

Ce que je voulais dire c'est que j'ai implanté 
mes "inverted index" par des tables PG (plutôt que par quelque chose de spécifique).

Merci pour les références et réponses ci-dessous, je vais regarder ça de plus prêt.

Mon application est destinée à être accédée via 
un serveur HTTP, c'est en fait un moteur de 
recherche sur un domaine spécifique 
(bio-technologie). Je ne pourrai en parler plus en détail que dans quelques mois...

Merci d'avance pour toute autre suggestion,

Francis Leboutte


> > Quelques unes de mes questions :
> >
> > - Quelles sont les bonnes sources d'information pour le règlage de tous
> > ces paramètres et l'optimisation (postgresql.conf, autres ?). Je n'ai
> > pas réussi à trouver un traitement exhaustif et suffisamment concret de
> > la question (par ex. PostgreSQL Hardware Performance Tuning de B.Momjian).
> >
>
> Celui que vous citez est intéressant mais malheureusement très ancien,
> pour ne pas dire obsolète.
>
> À ma connaissance, les deux meilleurs documents sur ce thème sont
> actuellement :
>
>  * "Performance Whack-a-Mole"
>    http://www.powerpostgresql.com/download/TFCKUpload/9.x-pdf
>
>  * "Fives steps to PostgreSQL Performance"
>    http://www.powerpostgresql.com/download/TFCKUpload/5.x-pdf
>
> > - Que peut-on faire quand la BD PG n'est accédée qu'en lecture seule et
> > qu'il n'y a pas d'accès concurrent ? Peut-on supprimer le mécanisme de
> > transaction ou d'autres non utiles dans ce cas ?
> >
>
> Le système des WAL n'est pas désactivable. Vous pouvez à la rigueur
> désactiver l'autovacuum mais cela ne vous fera rien gagner. Sans compter
> que vous devez quand même mettre à jour cette base de temps en temps, il
> faudra bien un VACUUM et un ANALYZE quelque part.
>
> > - Je voudrais que certaines tables soient en permanence en mémoire
> > (jamais swappée). Peut-on forcer ça ?
> >
>
> Non. C'est à l'OS et à PostgreSQL d'estimer ce qu'il convient le mieux
> de faire. Il pourrait se trouver un moment où une application prend
> tellement de mémoire que le système trouvera plus opportun de virer la
> table de la mémoire.
>
> En fait, vous pourriez le faire en déplaçant votre table sur un disque
> ram au démarrage, surtout que vous indiquez une utilisation en lecture
> seule. Dans ce cas, elle est physiquement stockée en mémoire, pas mise
> en cache.
>
> > - Peut-on mesurer la taille en mémoire d'une table (avec tout ce qui
> > l'accompagne) ?
> >
>
> Pas à ma connaissance.
>
> Si je puis me permettre, votre application se trouve dans quel type de
> système ? c'est de l'embarqué ? (c'est le coup du performance à tout
> prix, optimisation ram, lecture seule qui m'y fait penser)...
>
>
> --
> Guillaume.
> <!-- http://abs.traduc.org/
>      http://lfs.traduc.org/
>      http://docs.postgresqlfr.org/ -->
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster