SQL

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 uneautre 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)"