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

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

N'oubliez pas que vous devez faire un vacuum analyze table_a à chaque
création d'index afin de remettre à jour les stats disponibles pour
l'optimiseur, sinon il risque d'avoir un peu mal à la tête! :)

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;

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

Je suis curieux de connaître les résultats de ces tests, vous semblez
disposer d'une bases de données sérieuse ;-)

Merci pour votre retour sur cette liste, je pense que votre recherche et
vos résultats pourraient servir à tout le monde ici.

D'ailleurs je vous annonce ici la création prochaine sur le site
PostgreSQLFr.org d'une section particulière consacrée à la résolution de
problèmes divers et variés... En clair, il s'agira d'un document de type
"Livre", qui rassemblera plusieurs articles postés et à venir. A ce jour
un seul "Livre" existe sur le site c'est " Témoignage de pros"... Enjoy!
(Merci à Sébastien Dinot pour cette idée lumineuse!).

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

Non, pas de pragama / hints à la Oracle, que je sache (attention, j'ai
des 10aine de pages de doc à lire et re-lire avec la nouvelle version 8!)

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

Jean-Max dit vrai. Envoyer des "set enable_seqscan=off" (pour interdire
au postmaster de faire des full scan...) ne doit rester qu'une pratique
destinée aux tests...

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

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

http://developer.postgresql.org/docs/postgres/kernel-resources.html

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

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

Pour cela, la lecture de ma baffouille peut aider aussi:

http://www.argudo.org/postgresql/soft-tuning.php

Mais attention, mon article est bien vieux et dépassé à présent, je vais
le ré-écrire complètement afin de permettre aux gens d'utiliser
PostgreSQL 8 au mieux de ses capacités.

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

Oui, plus voir URLs ci-dessus, aussi. Elein est une grande spécialiste
de PostgreSQL...

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

--
Jean-Paul Argudo
www.PostgreSQLFr.org