IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

SQL Oracle Discussion :

Hash Semi Join VS Hash Join


Sujet :

SQL Oracle

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre Expert Avatar de pacmann
    Homme Profil pro
    Consulté Oracle
    Inscrit en
    Juin 2004
    Messages
    1 626
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Consulté Oracle
    Secteur : Distribution

    Informations forums :
    Inscription : Juin 2004
    Messages : 1 626
    Par défaut Hash Semi Join VS Hash Join
    Bonjour !

    Un truc que j'ai du mal à saisir : c'est quoi un HASH SEMI JOIN ???

    Je résume ce que j'ai compris "autour" du sujet.
    Le CBO choisit pour une requête un type, un algorithme de jointure en fonction du coût qu'il estime.

    Le HASH JOIN :
    - on crée un table de hashage pour A
    - on parcourt B, et on teste la valeur de hashage de la ligne

    Le SEMI JOIN (version nested loop) :
    - on parcourt la table A, on cherche les correspondances dans B, mais on s'arrête dès qu'on a trouvé.

    Comment est-ce qu'on peut concilier les deux ???
    (puis si on construit la hash table, puis on parcourt B, ce n'est qu'après avoir testé la valeur de hashage qu'on pourrait éventuellement savoir que ce n'était plus la peine de tester...)

    Merci !

  2. #2
    Expert confirmé Avatar de mnitu
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2007
    Messages
    5 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2007
    Messages : 5 611
    Par défaut
    Lis cet article

  3. #3
    Membre Expert Avatar de pacmann
    Homme Profil pro
    Consulté Oracle
    Inscrit en
    Juin 2004
    Messages
    1 626
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Consulté Oracle
    Secteur : Distribution

    Informations forums :
    Inscription : Juin 2004
    Messages : 1 626
    Par défaut
    Ok, merci, je crois que j'ai compris !

  4. #4
    Membre émérite
    Profil pro
    Inscrit en
    Août 2008
    Messages
    861
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2008
    Messages : 861
    Par défaut
    Ce serait possible de savoir ce qu'il en ressort s'il vous plait?

  5. #5
    Membre Expert Avatar de pacmann
    Homme Profil pro
    Consulté Oracle
    Inscrit en
    Juin 2004
    Messages
    1 626
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Consulté Oracle
    Secteur : Distribution

    Informations forums :
    Inscription : Juin 2004
    Messages : 1 626
    Par défaut
    Ok, petite explication

    La requête, avec des départements et des employés.
    Tu cherches tous les départements qui possèdent au moins un employé :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
     
    SELECT *
    FROM dept a
    WHERE EXISTS
      (SELECT 1
       FROM emp b
       WHERE a.id = b.depid)
    Oracle fait ce qu'on appelle un semi-join : c'est un peu comme une jointure, sauf qu'au lieu de chercher tous les couples résultants, tu t'arrêtes de chercher au premier trouvé.

    Pour faire la jointure, tu as deux méthodes :
    - NESTED LOOPS JOIN :
    tu parcours dept
    pour chaque ligne, tu prends l'id, et tu scannes l'index de emp pour retrouver la correspondance.
    Comme c'est un index, ça va vite a priori.
    Mais si tu as beaucoup de dept, pour peu de emp, les accès à l'indexe coutent malgré tout...
    Surtout si ta lecture par index te fait piocher dans pleins de blocs différent en alternance.

    - HASH JOIN :
    tu full scannes emp, et tu le HASH en mémoire sur la clef "depid".
    tu parcours dept, et pour chaque ligne, tu calcules la valeur de hashage, et tu interroges ta table de hashage.


    Voilà voilà, si tu veux jouer avec les avec Oracle, tu peux soit faire le bourrin comme dans l'article, soit te contenter de forcer avec les hints :
    - use_nl, use_hash
    - nl_sj, hash_sj


    PS : en ce qui me concerne, je m'étais juste emmêlé dans les histoires de A et B
    Merci Mnitu, et merci Tom !

  6. #6
    Membre émérite
    Profil pro
    Inscrit en
    Août 2008
    Messages
    861
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2008
    Messages : 861
    Par défaut
    Merci bien

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. left join , right join et inner join ?
    Par amine003 dans le forum Langage SQL
    Réponses: 3
    Dernier message: 05/12/2008, 17h25
  2. LEFT OUTER JOIN et LEFT JOIN
    Par polace dans le forum MySQL
    Réponses: 3
    Dernier message: 19/11/2008, 15h24
  3. NATURAL JOIN USING vs JOIN ON
    Par cbalmefrezol dans le forum Langage SQL
    Réponses: 3
    Dernier message: 15/10/2008, 09h45
  4. Réponses: 5
    Dernier message: 13/11/2007, 11h39
  5. [Mail] hash() : définir longueur du hash
    Par webrider dans le forum Langage
    Réponses: 5
    Dernier message: 17/08/2006, 14h58

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo