Optimisation requête jointure NOT IN

Bonjour,

J'ai actuellement une requête avec 5 jointures, dont une qui pose des problèmes de performance. La voici :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

SELECT DISTINCT commande.montant, commande.objet as objet, commande2.commande_num as numCommandeSpeciale   FROM ref.commande as commande     LEFT OUTER JOIN ref.commande as commande2 ON commande.commande_num = commande2.commande_num AND commande.colonne1 ='O' AND commande.statut IN ('XXX', 'YYY', 'ZZZ') AND commande2.commande_num NOT IN (SELECT DISTINCT commande_num FROM ref.table2 WHERE colonne1 IS NOT NULL)     WHERE commande.client = '000001'

---

Comment puis-je améliorer cela d'un point de vue performances sachant qu'il y a déjà les index adéquats.

Merci pour votre aide

Bonjour,

Indiquez le plan d’exécution réel de la requête.


Sinon je pense que vous réalisez une jointure en trop.

Un left join sur votre table de ref devrait suffire je pense, ensuite traiter la clause select avec un case / when

le plan d'exécution ?

cela ? :
Pièce jointe 160689

Je ne vois pas comment faire un left join tout simple à la place, car je souhaite conserver les enregistrements qui ne respectent pas la condition.

Sous pgadmin,

Faites un : explain analyze .....
... = la requete sql

Ensuite lancez-là et vous aurez le plan d'exécution en texte + les temps d'éxecution de la requête.


Bref sinon je viens de tester un peu, le left outer join + le test not in transforment la jointure en jointure interne.


du coup =>

Code:

---

1 2 3 4 5 6 7 8

select distinct commande.montant, commande.objet as objet, commande.commande_num as numCommandeSpeciale FROM ref.commande as commande AND commande.colonne1 ='O' AND commande.statut IN ('XXX', 'YYY', 'ZZZ') and not exists (select null from ref.table2 as B where b.colonne1 is not null and b.commande_num = commande.commande_num)

---

À noter que le 1er distinct est peut-être inutile.


Sous PostgreSQL il vaut mieux utiliser un not exists qu'un not in quand il y a une sous-requete.

Il peut alors utiliser des anti-join qui sont généralement plus rapides (voire beaucoup plus rapides selon le cas).

merci, je vais tester ça.