RE: [pgsql-fr-generale] Base de données PostgreSQL 8.0.0 de 200 G O - Problèmes de temps de réponse

De: Jean-Max Reymond [mailto:jmreymond(at)gmail(dot)com]
Date: jeudi 20 janvier 2005 10:45
À: ROELTGEN Pierre-Andre DSIC DESP
Objet: Re: [pgsql-fr-generale] Base de données PostgreSQL 8.0.0 de 200 G
O - Problèmes de temps de réponse

On Thu, 20 Jan 2005 10:35:46 +0100, ROELTGEN Pierre-Andre DSIC DESP
<Pierre-Andre(dot)ROELTGEN(at)interieur(dot)gouv(dot)fr> wrote:
>
>
> Bonjour;
>
> Sur une base de test PostgreSQL 8.0.0 (30 GO de "données brutes", 200 GO
de
> données et d'index sur disque) hébergée sur un système Linux 2.6, j'ai de
> graves soucis de temps de réponse. Toutes les opérations (analyze, vacuum,
> etc ...) ont été correctement effectuées. La base de données ne subit
> dorénavant plus de MAJ (insertion, suppression et modification). Voici
> quelques questions qui demandent aide de votre part :
>
> 1. Deux index créés et analysés sur une même table peuvent-ils être
utilisés
> en même temps lors de l'exécution d'une requête qui travaille sur cette
> table uniquement ?

je ne suis pas sur de bien comprendre la question.

==>==> En fait, je voudrais que l'index INDEX1 sur la colonne COL1 de la
table TABLE_A et l'index INDEX2 de la colonne COL2 de la même table TABLE_A
soient utilisés en même temps à l'exécution de la requête : fusion d'index
(INDEX MERGING), technique de hachage, etc ...

> 2. Peut-on orienter l'optimiseur sur les index de son choix (notamment
avec
> des hints ou directives à la mode Oracle) ?

non, pas à ma connaissance

==>==> OK. Merci.

> 3. Quels sont les paramètres du postgresql.conf qui vous semblent
pertinents
> à modifier ou prendre en compte, pour orienter l'optimiseur sur les index,
> au lieu de le laisser s'orienter sur des lectures séquentielles de tables
> (qui font quand même quelques dizaines de millions de lignes) ?

si tout est bien configuré, l'optimiseur ira au mieux. Il faut donc
bien configurer Postgres ;-) et ne pas oublier le VACUUM ANALYZE

==>==> En fait, le VACUUM ANALYZE a été fait de nombreuses fois.

> 4. Enfin, d'après votre expérience bien plus grande que la mienne,
possédez
> vous une liste d'URLs permettant enfin la mise en place d'un tuning
efficace
> de PostgreSQL ? (votre expérience vécue sur les paramètres du
> postgresql.conf).

un bon début est là:
http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html

==>==> Merci.

Après, il faut faire un EXPLAIN ANALYZE de tes requêtes trop lentes
pour pouvoir analyser ce qui se passe.

==>==> Ca, j'en ai hélas un peu trop la pratique.
==>==> Merci déjà pour tous ces conseils.

--
Jean-Max Reymond
CKR Solutions
Nice France
http://www.ckr-solutions.com