Cela peut valoir le coup d'utiliser un merge-sort join
(possiblement coûteux) si on demande les résultats dans un certain
ordre (ORDER BY compatible avec celui de la jointure). Cela évite de faire
une jointure suivie d'un tri.
@@ -452,7 +452,7 @@ uniformément réparties. Tous les sid et tous les bid sont présents
float:left;'>
-On choisi de faire d'abord une jointure entre R et S (i.e. un produit
+On choisi de faire d'abord une jointure entre B et S (i.e. un produit
cartésien car il n'y a pas de condition de jointure entre ces deux
tables). Puis la jointure de la table résultante avec B sur les
attributs (bid,sid).
@@ -461,13 +461,13 @@ attributs (bid,sid).
directement sur S, puis la jointure B &join;
(σ(S)). Pas d'utilisation d'index possible, jointure page
à page (car on génère tout le produit cartésien) : 100 Ã
- (100 + 200) = 300 000 E/S (pages) ou 192 000 000 enr.
+ (100 + 200) = 30 000 E/S (pages) ou 19 200 000 enr.
Puis jointure itérative page à page avec R (pas d'index sur R, pas d'index
- sur le résultat précédant qu'on vient de créer en mémoire):
- 1 000 Ã (300 000 + 1000) = 301 000 000 E/S.
+ sur le résultat précédent qu'on vient de créer en mémoire):
+ 1 000 Ã (30 000 + 1000) = 31 000 000 E/S.
-Coût total: 301 300 000 E/S (les projections sont faites
+
Coût total: 31 300 000 E/S (les projections sont faites
en pipline à la fin)
Plan complètement inefficace. On ignorera les plans contenant un
produit cartésien, sauf si c'est le seul moyen de calculer la
@@ -502,10 +502,10 @@ sur sid.
La deuxième jointure peut être faite à la volée (jointure itérative
par index sur S.sid) et la condition de sélection testée Ã
la volée. Coût total 100 000 à 3 (pour chacun des enregistrement
- précédants, on paye un accès d'index + un accès à la ligne
+ précédents, on paye un accès d'index + un accès à la ligne
correspondante dans S).
-Coût total: 601 000 E/S (les projections sont faites en pipline à la fin)
+Coût total: 601 000 E/S (les projections sont faites en pipline à la fin)