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

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

> > 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 sûr 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 ...
(Pierre-André)

si les deux champs (col1 et col2 de table_a) sont utilisés par vos
requetes vous avez tout intérêt à créer un index sur les deux à la fois:

Create index_1_2 on table_a (col1,col2);

Vous pourriez tester les résultats en comparant avec la création de deux
index distincts:

create index_1 on table_a (col1);
create index_2 on table_b (col2);

Dans un 1er temps, testez (un explain suffit..) avec index_1 et index_2
présents mais sans index_1_2. Ensuite, droppez index_1 et index_2, créez
index_1_2, testez.

Enfin, re-creés index_1 et index_2, en laissant index_1_2, testez:

Quels index l'optimiseur va t il choisir dans votre cas? Merci de
re-poster ici le résultat, pour analyse..

==>==> 1. Effectivement, la création d'index composite de type table_a
(index_1, index_2) améliore les choses, comme on peut s'en douter.
Néanmoins, nous considérons notre base comme un datawarehouse. Il est
sémantiquement impossible de créer des dizaines et des dizaines d'index
composites. Les techniques de fusion d'index (index merge) pratiqués par
l'optimiseur d'autres SGBDRs améliore de façon exponentielle les temps de
réponse. (Pierre-André)

Enfin, vous pouvez aussi ré-organiser les données à l'interieur de la
table en fonction d'un index. Par exemple, faire en sorte que les
données soient organisées selon index_1_2; utilisez CLUSTER:

cluster index_1_2 on table_a;

==>==> 1 Bis. Merci pour l'idée. Mais cette solution n'est probablement pas
adaptée à notre base de données. (Pierre-André)

Et encore une fois, vacuum full analyze puis re-tests..

> > 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

==>==> 3. Même question que Xavier Poinsard. (Pierre-André)

Si votre serveur est plutôt puissant, faites en sorte que le cout du
hasard soit moins cher, soit baissez la valeur de random_page_cost,
souvent à 4 par défaut à 2 ou 1.. et re-testez...

==>==> 4. Positionné à 1 puis remis à 2. Sans grandes conséquences.
(Pierre-André)

Faites attention à permettre à PostgreSQL d'utiliser la mémoire du
système comme il faut: augmeter les parametres kernel shmemall et
shmemmax.. voir documentation:

==>==> 5. Fait. Sinon, PostgreSQL ne peut pas démarrer. (Pierre-André)

Pour un tuning un peu plus "hard", je vous reccomande la lecture du
document de Bruce:

http://www.ca.postgresql.org/docs/momjian/hw_performance/0.html

Cela devrait répondre à vos questions sur le postgresql.conf

==>==> 6. Toutes les docs que vous mentionnez sont effectivement
intéressantes. La plupart sont déjà connues; elles méritent toutefois de
notre part une relecture attentive. (Pierre-André)

Sachez toutes fois que dans 3 cas sur 4, ce sont les requêtes
elles-mêmes qui sont en cause en cas de mauvaises performances (en tout
cas, c'est la statistique que je me suis faite depuis mes qques années
de pratique de PostgreSQL... ;-) )

==>==> 7. C'est vrai. Mais nos requêtes sont le plus souvent simples. En
voici une, typique:
select listes_cols from table_a where col1 = 'truc' and col2 like 'CHOSE%'
and col3 in ('A', 'B'); (Pierre-André)

> 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.

L'utilisation d'EXPLAIN est simplissime avec PG, il suffit d'ajouter le
mot-clé "EXPLAIN" devant toute requête DML:

EXPLAIN SELECT...;

Et le plan d'exécution apparaît! Rien à voir avec d'autres SGBDR ou
plusieurs manipulations sont à faire ...

==>==> 8. Tout à fait. Sympa comme fonctionnalité. (Pierre-André)

Bien Cordialement.