SQL

1. Travail 1 : Synthèse
1.1 – Planificateur/Optimiseur :
La tâche du planificateur/optimiseur est de créer un plan d'exécution optimal. En fait, une requête SQL
donnée (et donc, l'arbre d'une requête) peut être exécutée de plusieurs façons, chacune arrivant au même
résultat. Si cecalcul est possible, l'optimiseur de la requête examinera chacun des plans d'exécution
possibles pour sélectionner le plan d'exécutionestimé comme le plus rapide.
La procédure de recherche du planificateur fonctionneavec des structures de données appelées
chemins, simples représentations minimales de plans ne contenant que l'informationnécessaire au
planificateur pour prendre ses décisions. Une foisle chemin le moins coûteux déterminé, un arbre plan est
construit pour être passé à l'exécuteur. Celui-ci représente le plan d'exécution désiré avec suffisamment de
détails pour que l'exécuteur puisse le lancer. Dans le reste de cette section, la distinction entre chemins et
plans est ignorée.
Le planificateur/optimiseur commence par engendrer des plans de parcours de chaque relation (table)
invididuelle utilisée dans la requête. Les plans possibles sont déterminés par les index disponibles pour
chaque relation. Un parcours séquentiel de relation étant toujours possible, un plan de parcours séquentiel
est systématiquement créé. Soit un index défini sur une relation (par exemple un index B-tree) et une
requête qui contient le filtre relation.attribut OPR constante.Sirelation. Attribut correspond à la clé de
l'index B-tree et OPRest un des opérateurs listés dans la classe d'opérateurs de l'index, un autre plan est
créé en utilisant l'index B-tree pour parcourir la relation. S'il existe d'autres index et que les restrictions de
la requête font correspondre une clé à un index, d'autres plans sont considérés. Des plans de parcours
d'index sont également créés pour les index dont l'ordre de tri peut correspondre à la clause ORDERBY de
la requête (s'il y en a une), ou dont l'ordre de tri peut être utilisé dans une jointure de fusion (cf.plus bas).
Si la requête nécessite de joindre deux, ou plus, relations, les plans de jointure des relations sont
considérés après la découverte de tous les plans possibles de parcours des relations uniques. Les trois
stratégies possibles de jointure sont :
- jointurede boucleimbriquée(nestedloopjoin) : la relation de droite est parcourue une fois pour
chaque ligne trouvée dans la relation de gauche. Cette stratégie est facileà implanter mais peut être
très coûteuse en temps. (Toutefois,si la relation de droite peut être parcourue à l'aide d'un index, ceci
peut être une bonne stratégie. Il est possible d'utiliser les valeurs issues de la ligne courante de la
relation de gauche comme clés du parcours d'index à droite.)
- jointurede fusion(mergejoin) : chaque relation est triée selon les attributs de la jointure avant que la
jointure ne commence. Puis, les deux relations sont parcourues en parallèle et les lignes
correspondantes sont combinées pour former des lignes jointes. Ce type de jointure est plus
intéressant parce que chaque relation n'est parcourue qu'une seule fois. Le tri requis peut être réalisé
soit par une étape explicite de tri soit en parcourant la relation dans le bon ordre en utilisant un index
sur la clé de la jointure.
- jointurede hachage(hashjoin) : la relation de droite est tout d'abord parcourue et chargée dans une
table de hachage en utilisant ses attributs de jointure comme clés de hachage. La relation de gauche
est ensuite parcourue et les valeurs appropriées de chaque ligne trouvée sont utilisées comme clés de
hachage pour localiser les lignes correspondantes dans la table.
Quand la requête implique plus de deux relations, le résultat final doit être construit à l'aide d'un arbre
d'étapes de jointure, chacune à deux entrées. Le planificateur examine les séquences de jointure possibles pour
trouver le moins cher. Si la requête implique moins de geqo_thresholdrelations,une recherche quasi-
exhaustive est effectuée pour trouver la meilleure séquence de jointure. Le planificateur considère
préférentiellement les jointures entre paires de relations pour lesquelles existe une clause de jointure
correspondante dans la qualification WHERE (i.e.pourlesquelles existe une restriction de la forme where
rel1.attr1=rel2.attr2).Lespaires jointes pour lesquelles il n'existe pas de clause de jointure ne sont
considérées que lorsqu'il n'y a plus d'autre choix, c'est-à-dire qu'une relation particulière n'a pas de clause de

2. jointure avec une autre relation. Tous les plans possibles sont créés pour chaque paire jointe considérée par le
planificateur. C'est alors celle qui est (estimée) la moins.
1.2– Annexe :
1.2.1– SansLEFT JOIN :
Requête :
Résultat :
Requête :
Résultat :
1.2.2– Avec LEFT JOIN:
Requête :
Résultat :
SELECT * FROM p,u,puf WHERE puf.np = p.np AND puf.nu = u.nu
EXPLAIN SELECT * FROM p,u,puf WHERE puf.np = p.np AND puf.nu = u.nu
"Nested Loop (cost=1.28..37.99 rows=39 width=177)"
" -> Hash Join (cost=1.14..29.54 rows=39 width=105)"
" Hash Cond: (puf.nu = u.nu)"
" -> Seq Scan on puf (cost=0.00..23.10 rows=1310 width=32)"
" -> Hash (cost=1.06..1.06 rows=6 width=73)"
" -> Seq Scan on u (cost=0.00..1.06 rows=6 width=73)"
" -> Index Scan using p_pkey on p (cost=0.15..0.21 rows=1 width=72)"
" Index Cond: (np = puf.np)"
SELECT * FROM u LEFT JOIN (puf JOIN p ON (puf.np = p.np)) ON (u.nu = puf.nu)

3. Requête :
Résultat :
1.3 - Commentaires :
D’un premier coupon voitque les résultats sont identiques, l’utilisation de l’EXPLAINpour voirle cout
de chaque requête montre que dans la première requête qu’on laisse au SGDB (Dans ce cas PostgreSQL) le
choix le cout est très faible environ 1,28… (Voir 1.2.1), mais lorsque on impose sur lui l’utilisation de LEFT
JOINon voit que le coutde la requête est très élevé par rapport au premier.
Explication : PostgreSQL utilise l’optimisateur des requetés pour décider qu’elle est la meilleure
méthode et qu’elle a le moindre couten utilisant les INDEX.
EXPlAIN SELECT * FROM u LEFT JOIN (puf JOIN p ON (puf.np = p.np)) ON (u.nu = puf.nu)
"Hash Right Join (cost=29.13..75.55 rows=39 width=177)"
" Hash Cond: (puf.nu = u.nu)"
" -> Hash Join (cost=28.00..69.11 rows=1310 width=104)"
" Hash Cond: (puf.np = p.np)"
" -> Seq Scan on puf (cost=0.00..23.10 rows=1310 width=32)"
" -> Hash (cost=18.00..18.00 rows=800 width=72)"
" -> Seq Scan on p (cost=0.00..18.00 rows=800 width=72)"
" -> Hash (cost=1.06..1.06 rows=6 width=73)"
" -> Seq Scan on u (cost=0.00..1.06 rows=6 width=73)"