Update and exists

Bonjour,

lors d'une mise à jour d'une colonne de table à partir d'un sous-select, est-ce qu'il y a un intérêt à ajouter une condition EXISTS pour vérifier si la jointure retourne quelque chose.

Est-ce qu'il y a un impact performance à l'utilisation de la clause exists dans ce cas de figure ? Et si oui lequel ?

Code:

---

1 2 3 4 5 6 7

Update perf_tab1 t0 set t0.object_type = (select t1.object_type from perf_tab2 t1 where t1.object_id = t0.object_id) where exists (select 1 from perf_tab2 t1 where t1.object_id = t0.object_id);

---

Bonjour,

Oui bien sûr qu'il y a un intérêt. Sans clause WHERE toutes les lignes de la table seront mises à jour. Donc si ton sous-select ne ramène rien pour certaines id, alors tu mettras NULL dans object_type. Si c'est le but recherché, alors en effet la condition EXISTS n'est pas nécessaire.
Quand je dois faire une mise à jour de données pour lesquelles j'ai besoin des données source pour la mise à jour, j'utilise un MERGE, moins coûteux car données source lues qu'une fois (et syntaxe plus souple aussi);

Et merge fusionne des mini-index avec les index de la cible à la fin au lieu de les mettre à jour ligne à ligne.

Merci pour vos retour

J'avais été au plus simple mais la table mise à jour est bien conditionné ppour ne mettre à jour que certains enregistrements (ici j'ai ajouté pour l'exemple object_type = 'TABLE').

Dans ce cas de figure, les lignes de ma table t0 qui n'ont pas de correspondances dans t1 seront mises à jour avec Object_type à null si je ne mets pas de clause EXISTS ?

Code:

---

1 2 3 4 5 6 7 8 9 10

Update perf_tab1 t0 set t0.object_type = (select t1.object_type from perf_tab2 t1 where t1.object_id = t0.object_id) where exists (select 1 from perf_tab2 t1 where t1.object_id = t0.object_id) and t0.object_type = 'TABLE';

---

Si je suis en mesure de garantir qu'il y a un correspondance, du coup il ne faut mieux pas utiliser EXISTS ? J'ai bon ?

Pour l'utilisation avec MERGE j'ai essayé avec ces instructions,

Code:

---

1 2 3 4 5

MERGE INTO perf_tab1 t0 USING perf_tab2 t1 ON (t0.object_id = t1.object_id) WHEN MATCHED THEN UPDATE SET t0.object_type = t1.object_type WHERE t0.object_type = 'TABLE';

---

Les tests effectués sont sans appel :

Ecoulé : 00:00:00.415 avec l'utilisation du merge
Ecoulé : 00:06:33.682 avec update classique sans utilisation du EXISTS
Ecoulé : 00:06:38.002 avec update et utilisation du EXISTS

Les tests confirment bien une mise à jour à null si pas de correspondance trouvé entre la table mise à jour et a table de référence.

@WALDAR : Peux-tu STP préciser "Et merge fusionne des mini-index avec les index de la cible à la fin au lieu de les mettre à jour ligne à ligne."

Tu vois que le MERGE est non seulement plus pratique, mais il est plus rapide ici.
J'utilise UPDATE uniquement quand je dois mettre à jour avec des valeurs en dur, par exemple:

Code:

---

1 2 3

UPDATE t set status = 2, modification_date = sysdate WHERE ....

---

Si les valeurs servant à la mise à jour proviennent d'autres tables, alors j'utilise MERGE, comme dans ton exemple.

Bonjour,

petite précision qui a son importance, les tests ont été réalisés sans index.

Lorsque que positionne les bons index, l'instruction avec le update classique avec EXISTS est plus rapide (Ecoulé : 00:00:00.293)

Citation:

---

Envoyé par grouhan

Les tests effectués sont sans appel :

@WALDAR : Peux-tu STP préciser "Et merge fusionne des mini-index avec les index de la cible à la fin au lieu de les mettre à jour ligne à ligne."

---

Lorsque le MERGE peut se faire en "direct path load" (via l'utilisation du hint append par exemple) les indexes sont maintenus en bulk à la fin du MERGE (ou de l'INSERT)

Code:

---

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

MERGE /*+ append */ INTO t2 USING (SELECT * FROM t1) h ON (t2.n1 = h.n1) WHEN MATCHED THEN UPDATE SET t2.d1 = h.d1 WHEN NOT MATCHED THEN INSERT (n1, d1) VALUES (h.n1, h.d1);   10 rows merged.   SQL> select * from t2; select * from t2 * ERROR at line 1: ORA-12838: cannot read/modify an object after modifying it in parallel

---

Dans le modele que j'ai présenté plus haut les 10 lignes mergées l'ont été via un INSERT. Et comme je ne peux pas séléctionner de la table t2 avant de commiter cela veut dire que l'INSERT a bien été fait en "direct path load". Et dans ce cas la maintenance des indexes est plus performante.

Bien Cordialement
Mohamed