SQL Server Execution Plans - Red Gate Software

Chapter 5: Controlling Execution Plans with Hints
Original (Hash)
Table 'Illustration'. Scan count 1, logical reads 273
Table 'ProductModelIllustration'. Scan count 1, logical reads 183
Table 'Worktable'. Scan count 0, logical reads 0
Table 'ProductModel'. Scan count 1, logical reads 14
Table 'Product'. Scan count 1, logical reads 15
Loop
Table 'Illustration'. Scan count 1, logical reads 273
Table 'ProductModelIllustration'. Scan count 1, logical reads 183
Table 'Product'. Scan count 1, logical reads 555
Table 'ProductModel'. Scan count 1, logical reads 14
Merge
Table 'Illustration'. Scan count 1, logical reads 273
Table 'Worktable'. Scan count 0, logical reads 0
Table 'ProductModelIllustration'. Scan count 1, logical reads 2
Table 'Product'. Scan count 1, logical reads 15
Table 'ProductModel'. Scan count 1, logical reads 14
This shows us that the Hash Match and Nested Loops joins required almost exactly the
same number of reads as the Merge Join to arrive at the required data set. The differences
arise when we see that, in order to support the Nested Loops join, 555 reads were required
instead of 15 for both the Merge Join and Hash Match. The key difference is the number
of reads of the ProductModelIllustration table in the Merge Join; it's only 2, as
opposed to the 183 in the other two queries.
This illustrates the point that the optimizer does not always choose an optimal plan.
It's always best to look at the properties of the Select operator to see if full optimization
occurred and if there was a timeout. Neither was the case here; it was a full optimization
and the optimizer thought it found the best possible plan in the time allotted. Based on
the statistics in the index and the amount of time it had to calculate its results, it must
have decided that the Hash Match would perform faster.
Although we've positively influenced query performance for the time being, the downside
is that, as the data changes over time within the tables, it's possible that the Merge Join
will cease to function better. However, because we've hard coded the join, no new plan
will be generated by the optimizer as the data changes, as would normally be the case.
217