Join Algorithms

Join Algorithms - 1 There are 6 join Algorithms These are the 6 ways that the optimiser can choose to use to solve a join They all have differing advantages Some may be better for larger or smaller tables Some may work better for complex (more than 2 table) joins

Join Algorithms - 2 You have some limited ability to affect the join algorithms used This is probably not that useful Knowledge of the joins and there strengths and weaknesses can help in the decoding of the query plans This can then allow you to see where the query may be running slowly – and change this

The Big 6 The 6 Join Algorithms are : –Nested Loop JoinNLJ –Nested Loop PushdownNLPD –Hash JoinHJ –Hash Join PushdownHPDJ –Sort Merge JoinSMJ –Sort Merge PushdownSMPDJ

Nested Loop Join Take Small Table (or result set) Store it For each row in the Big Table, compare with each row in the Small Table Store

Nested Loop Pushdown Reverse of the Nested Loop For each Row in the Small Table Probe a fast index(LF or HG) on the Big Table

Hash Join (Classic Hash) Create a hash table for the Small Side For each row in the Big Table probe the Hash Table for Join Conditions Used when small side < 1,250,000 rows in a two table join Used when the ratio between the large side and small side <600:1 in a more than two table join “Classic Hash” - needs to be kept in memory

Hash Join Pushdown If the Distinct Count of T3.X is small –i.e.T3 is a small table or T4 predicate can filter T3xT4 to small size Then I.2 has a hash table keyed on T3.X and I.2 is complete Create an Artificial IN Clause on T1 to filter out rows that do not satisfy T1.X=T3.X T1T2T3T4 I.1 I.2 R1T1.X=T3.X

Sort Merge Join Sort on both sides then merge result sets Used in all other cases Optimised now (12.4) for 1:M (Primary or UNIQUE Join Key) There is an exception in the case of M:M join, when there is a Loop against the small side

Sort Merge Pushdown - 1 Similar to the Hash Pushdown But in this case there are too many rows from I2 to store in a Classic Hash Instead we compute a hash table (as a bit vector) to report that 1 or more rows in I2 have the hash value Also there is more than 1 key matching the hash number New T1T2T3T4 I.1 I.2 R1

Sort Merge Pushdown - 2 We have a “Probably IN” Hash table Push Down the Bit Vector to T1 Now we know that if the hash # is NOT in the hash table then we know that the key value is NOT going to match at R1 If the Key # IS in the hash table then it MAY match and should go up to I.1 and R1 New T1T2T3T4 I.1 I.2 R1

Join Optimisation Join_Optimization Def ON –Switching this off will set the optimiser to parse the join tree left to right – as the table were specified in the from clause –This may help an individual query – but generally this should only be used if you have drawn out the query tree and you are certain that the optimiser has misjudged the query

Join Preference Join_Algorithm_Preference –0Let the optimiser choose - default –1/-1Prefer/Avoid Sort/Merge –2/-2Prefer/Avoid Nested Loop –3/-3Prefer/Avoid Nested Loop Pushdown –4/-4Prefer/Avoid Hash Join –5/-5Prefer/Avoid Hash Join Pushdown –6/-6Prefer/Avoid Pre-join Indexes –7/-7Prefer/Avoid Sort/Merge Pushdown

Extended_Join This option controls the allowing of ambiguous syntax joins shouldWith the ANSI join syntax there should be no ambiguity With the “old fashioned” method of joining there could be ambiguity If this option is ON (default) then the query will be thrown out with a syntax error If not the query will be run using the plan that has the lowest cost

Join Algorithms - End