Discussion :

[chmanu]

Bonjour,

Je vous expose mon petit souci que je n'arrive pas à expliquer :
SELECT num, idf
FROM NFAC
WHERE num NOT IN (
SELECT numfac FROM
PFACT@DBL factdist)
me mets 46s

Alors que
SELECT num, idf FROM NFAC left join PFACT@DBL factdist on factdist.numfac = NFAC.num WHERE factdist.numfac is null
ne met que 1s.

Volumétrie : 1000 sur la table locale, 200000 sur la distante.

Il me semblait qu'oracle interprétait la requête afin de prendre en compte le meilleur plan (CBO) ; les dblink feraient ils exception (mes stats sont ok sur les deux bases) ?

Enfin, question subsidiaire, j'ai essayé d'utiliser le hint /*+DRIVING_SITE(factdist) */ sans succès, les plans et temps sont les mêmes. Y a t-il un parametre à modifier ?

Merci d'avance,

Chmanu

[Waldar]

Vous pouvez faire le même test avec deux tables en locales, le "NOT IN" et le "LEFT JOIN ... IS NULL" ne génèrent pas le même plan d'exécution.

Par contre "LEFT JOIN ... IS NULL" est similaire à "NOT EXISTS".
Ces deux dernières solutions sont toujours plus performantes que "NOT IN", avec les bons indexes.

[PpPool]

Vous pouvez faire le même test avec deux tables en locales, le "NOT IN" et le "LEFT JOIN ... IS NULL" ne génèrent pas le même plan d'exécution.

Par contre "LEFT JOIN ... IS NULL" est similaire à "NOT EXISTS".
Ces deux dernières solutions sont toujours plus performantes que "NOT IN", avec les bons indexes.

+1 partons en lutte pour bannir le NOT IN avec requete imbriquée

[skuatamad]

Je pense qu'il est plus prudent de ne pas être radical, cf tom kyte que je lisais justement ce matin :
http://asktom.oracle.com/pls/asktom/...:8764517459743

I've talked to people who swear "NOT IN" is fatal,
never use it - always use NOT EXISTS. Then I show them NOT IN running a query 10 times
faster then NOT EXISTS. I talk with people who feel NOT EXISTS is the worst construct
on the planet - you must use IN. Then I do the same - showing them how NOT EXISTS can
run many times faster then IN.