i was not able to see that aspect. Truely impressed with your way of thinking.

Thanks

Consider: if your 10 “unique” rows in T1 are 32KB each and your 1,000 “non-unique” rows in T2 are 12 bytes each, then Oracle might choose to build the hash table from T1.

When you say that the rows in T1 are unique, do you mean that they are unique as far as the join column(s) are concerned – and are the 1,000 “non-unique” rows distributed so that there are roughly 100 rows from T2 to join to each row in T1 ?

As far as the appeal of your hypothesis is concerned, you seem to be thinking only of the speed with which the hash value can be calculated. Have you considered the extra cost (and mechanics) of creating a hash table that contains more data ? Have you considered what happens if the larger data set can’t fit into memory ? Have you considered the cost of “probing a hash bucket” and finding that you have to follow a linked list to another 99 matching values in that bucket – if that 100 to 1 join is the thought behind your example.

in case we create hash table from T2(100) non unique rows which exists in hash buckets and probe it with T1. i.e take a row from T1 calculate its hashing key and then use the hash key to reach the hash bucket of memory table T2. this theory looks more appealing to me.

I do not know the hashing function used by Oracle. However the in-memory hash table will have a number of buckets that is a power of 2 (in fact it might even be a power of 4) – and Oracle has a couple of hash functions based on generating value between 1 and 2^N that could be used.

Based on your description there is no guarantee that Oracle would choose to do a hash join – but if it did, and if its predicted cardinalities were realistic assessments of the figures you have given me then it would probably build the hash table from the 10 rows from t1 and probe it with the 1,000 rows from t2.

I am a bit confused. for hashing you need a hash function who oracle calculates it. secondly if i have two tables T1 containing 10 unique rows and other T2 table containing 1000 non unique rows. will oracle place T1 in PGA memory or T2 or it create a memory hash table with T2 and gets T1 from buffer cache and for each row of T1 gets the subsets of rows from T2, nested loops them and return to us. will you please elobrate?

regards
Amir Riaz

I was just browsing some notes by Alex Fatkulin, and it crossed my mind that perhaps NLJ_BATCHING may be a mechanism that allows the “consistent gets (fastpath)” to appear more frequently.

(Just another thing to add to the list of ideas when I get around to looking at it properly.)

Thanks for the wonderful article, this was very helpful.

I have few doubts though, may be my oracle knowledge isnt good enough :(

could you please elaborate this statement as in the explanation above?

a hash join is a nested loop join where Oracle has extracted a subset of the data from the thing that was the “inner” table.

I just want to know how does Oracle does this, is it that we create Hash Table and then fire the select query? kindly clarify this.

Thanks,
Kartik

If you’re expecting to join 10 rows from a small table to 10 row from a large table, you don’t have a “small data set” and a “large data set” – you have two small data sets and the topic is irrelevant.

If you have Vipin’s data sets: (100 rows in table with PK, 10,000,000 rows in table with FK) then do you want to join them with:

NLJ from small to big
NLJ from big to small
NLJ from big to small after (permanently)recreating small as single table hash cluster
HJ with small as build table
MJ – but we’ll ignore that one for now

Now you can probably see the sense of comparing NLJ with HJ.

In passing, I was talking about latch gets, not buffer visits – some buffer visits require two latch gets. Depending on version, infrastructure, data patterns, and environment I could probably make the actual number vary from a few tens of thousands to an arbitrarily large number. The 40M is a ball-park figure to indicate order of magnitude in a fairly bland boring system joining a couple of heap tables with indexes.

I like his use of the “repeatable test case”.