SlideShare une entreprise Scribd logo
1  sur  3
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
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)
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)"

Contenu connexe

En vedette

La Felicidad
La FelicidadLa Felicidad
La FelicidadCMFLVB
 
Autos electricos(1)
Autos electricos(1)Autos electricos(1)
Autos electricos(1)Luis Lago
 
Rec casac fondo (familia)rechazado
Rec casac fondo (familia)rechazadoRec casac fondo (familia)rechazado
Rec casac fondo (familia)rechazadoneitabelen
 
Presentación de informes
Presentación de informesPresentación de informes
Presentación de informesjulio150241
 
Introduccion a la tecnología educativa
Introduccion a la tecnología educativaIntroduccion a la tecnología educativa
Introduccion a la tecnología educativaMagda Collazo
 
trabajo de literatura infantil 2
trabajo de literatura infantil 2trabajo de literatura infantil 2
trabajo de literatura infantil 2nely_villalba
 
Tutorial EducaTIC Bell Ville
Tutorial EducaTIC Bell VilleTutorial EducaTIC Bell Ville
Tutorial EducaTIC Bell VilleXavi Vinyals
 
Récapitulatif
RécapitulatifRécapitulatif
Récapitulatifumberine
 
Argentina en imágenes
Argentina en imágenesArgentina en imágenes
Argentina en imágenesjdlu
 
Eolien et solaire : faisons le point en images !
Eolien et solaire : faisons le point en images !Eolien et solaire : faisons le point en images !
Eolien et solaire : faisons le point en images !RTE
 

En vedette (17)

La Felicidad
La FelicidadLa Felicidad
La Felicidad
 
Ex.le gérondif
Ex.le gérondifEx.le gérondif
Ex.le gérondif
 
Présentation Tirer parti des Avis Clients - Novembre 2015
Présentation Tirer parti des Avis Clients - Novembre 2015Présentation Tirer parti des Avis Clients - Novembre 2015
Présentation Tirer parti des Avis Clients - Novembre 2015
 
Autos electricos(1)
Autos electricos(1)Autos electricos(1)
Autos electricos(1)
 
Rec casac fondo (familia)rechazado
Rec casac fondo (familia)rechazadoRec casac fondo (familia)rechazado
Rec casac fondo (familia)rechazado
 
Collaboration banques
Collaboration banquesCollaboration banques
Collaboration banques
 
Presentación de informes
Presentación de informesPresentación de informes
Presentación de informes
 
Introduccion a la tecnología educativa
Introduccion a la tecnología educativaIntroduccion a la tecnología educativa
Introduccion a la tecnología educativa
 
Guias de taller
Guias de tallerGuias de taller
Guias de taller
 
trabajo de literatura infantil 2
trabajo de literatura infantil 2trabajo de literatura infantil 2
trabajo de literatura infantil 2
 
Tutorial EducaTIC Bell Ville
Tutorial EducaTIC Bell VilleTutorial EducaTIC Bell Ville
Tutorial EducaTIC Bell Ville
 
Récapitulatif
RécapitulatifRécapitulatif
Récapitulatif
 
Pps mars 2013
Pps mars 2013Pps mars 2013
Pps mars 2013
 
Slide show Tempotraxx
Slide show TempotraxxSlide show Tempotraxx
Slide show Tempotraxx
 
Viator web052fr
Viator web052frViator web052fr
Viator web052fr
 
Argentina en imágenes
Argentina en imágenesArgentina en imágenes
Argentina en imágenes
 
Eolien et solaire : faisons le point en images !
Eolien et solaire : faisons le point en images !Eolien et solaire : faisons le point en images !
Eolien et solaire : faisons le point en images !
 

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