optimisation d'une requête avec jointure [Résolu]

[champijulie]

Bonjour à tous.

J'ai fait un explain sur une requête sous Oracle et sous Postgre (la même traduite suivant que j'utilise Oracle ou PostgreSQL) que je vous donne (version Postgre):

Code :

1
2
3
4
5
6
SELECT count(*) FROM 
(
SELECT D."ID_DOSSIER", "NOMDOSSIER"
FROM ddc_appia."DOSSIER" D LEFT OUTER JOIN ddc_appia."DOSSIERETAT" DE ON D."ID_DOSSIER" = DE."ID_DOSSIER"
WHERE (DE."ID_ETAT" = 2 OR DE."ID_ETAT" IS NULL)
) x ;

Et là, je constate une chose bizarre. Sous Oracle, il y a l'utilisation d'un index sur dossieretat alors qu'il n'est pas utilisé sous PostgreSQL.
Je me suis dit que si il était utilisé sous Oracle et que les deux requêtes étaient identiques alors PostgreSQL devrait l'utiliser également. Non?

Je ne sais pas comment le faire pour lui faire utiliser cet index. Y a t il un moyen de le forcer à l'utiliser ou de lui rappeller qu'il existe un index qu'il pourrait accessoirement utiliser?
Merci d'avance de me répondre.
champijulie.

[champijulie]

J'ai constaté un petit truc rigolo :
J'exécute cette requête sur trois bases différentes par la taille mais qui ont la même structure:
pour la plus petite base : utilisation de 2 index
pour la moyenne base : utilisation d'un seul index
pour la grosse base : aucune utilisation d'index

Alors que ce sont les mêmes tables avec les mêmes index et la même requête. Et là, j'avoue que je ne comprend pas.
les index prennent en compte la taille de la table au nuveau de données ????

Je ne sais pas quoi penser...
champijulie

[GrandFather]

Bonjour,

pour pouvoir choisir une stratégie efficace d'exécution des requêtes utilisateurs, Postgres a besoin de stats sur les tailles (nb d'enregistrements) des tables, les indexes, etc.

Pour constituer ces stats, il faut lancer assez régulièrement la commande suivante :

Code :

VACUUM ANALYZE

[champijulie]

Je viens d'en faire un mais il bloque sur une violation d'index dans la table pg_statistic du schéma pg_catalog qui est un schéma système auquel je n'ai pas touché.
Je ne sais pas quoi faire pour remédier à cette erreur. Il me marque:
ERROR: duplicate key violates unique constraint "pg_statistic_relid_att_index"
J'essaie depuis tout à l'heure de voir d'où ça peut provenir. En efeet, il y a des doublons sur cette table par rapport à l'index mais je ne vois pas comment il aurait pu être inséré.

@+
champijulie

[GrandFather]

Tu es sur quelle version de PostgreSQL ?

[champijulie]

Version 8.0.2 pour Windows

[GrandFather]

Curieux...
La seule mention de ce problème que j'ai trouvée est cette URL : http://qaix.com/postgresql-database-...dex-read.shtml

Avant de faire ce que préconise Tom Lane dans sa réponse, je te conseille quand même de faire une sauvegarde complète de tes bases (on n'est jamais trop prudent)...

[champijulie]

J'ai suivi son conseil et le tien par la même occasion.
Ca a l'air de fonctionner mais c'est vraiment radical comme solution...

Merci beaucoup pour ton aide
@ la prochaine
champijulie

[champijulie]

Ca c'est améliorer dans le sens où maintenant il utilise un peu plus les index mais c'est pas encore gagné car il ne les utilise pas tous et je ne sais pas comment le forcer à les utiliser...

Merci de me répondre
champijulie.