I’ve grown up reading Tom Clancy and probably most of you have at least seen Red October, so this book caught my eye when browsing used books for a recent trip. It’s a fairly human look at what’s involved in sailing on a Trident missile submarine…
Before we start Adaptive Joins, SQL Server’s Query optimizer internally has 3 join types.
Nested Loop Join – Usually picked by optimizer, when tables participating in the joins are small or when one of the table is big and indexed on joining column
Hash Join: One of the table is big but doesn’t have an index
Merge Join: Both the tables are big, and the joining column is indexed
So, the size of the table or the rows participating in the join plays a major role SQL’s Query optimizer picking the correct join type. Let’s say, SQL Server estimates few rows participating in the join at compile time and picks “nested join” but during runtime, the join extracts larger number of rows and thereby making the choice of plan ineffective.
SQL Server 2017’s adaptive join addresses this problem. With Adaptive Join, SQL Server comes with plan attribute called “Adaptive Row Threshold” which is a row count threshold estimated by SQL Server. “Adaptive Row Threshold” will help SQL Server dynamically alter the plan choice at run time. Adaptive join in short will work in the following way
If the number of rows participating in the join are greater than “Adaptive Row Threshold” rows, then “Hash Join” operator is used for join operation
If the number of rows participating in the join are lesser than “Adaptive Row Threshold” rows, then “Nested loop Join” operator is used for join operation