If you thought that title sounded familiar, you sure were right.
That’s called a classical reference.
So here we are, three whole years later, and yet another improvement to the engine promises to fix performance issues forever and ever.
While this isn’t exactly an entirely new cardinality estimator, it’s an entirely new branch in the cardinality estimation process.
Or as I’m going to call them, the Mr. Destiny Join.
You see, in every plan, you see both possible paths the optimizer could have chosen. Right now it’s only limited to two choices, Nested Loops and Hash Joins.
Just guessing that Merge Joins weren’t added because there would have been additional considerations around the potential cost of a Sort operation to get the data in order.
Fun, right? Ever see a Sort in a query plan where you didn’t write an ORDER BY? Sometimes SQL will act like your mom and say “I’ll just straighten up your room for you” but then she finds the box under your bed and, well, anyway.
I’m 36 and I’m finally not grounded.
Why this is awesome
With Adaptive Joins, the optimizer is way less “that’s not an iceberg” about the way it chooses query plans. It’ll go ahead and run some tests to make sure that it is, in fact, not an iceberg, before steering plan choices in a particular direction. This can be particularly helpful for non-SARGable queries, where the optimizer would usually way overestimate rows, and ask for all sorts of memory and CPU and other knick-knacks and whirlygigs to compensate.
I’m going to be kicking the wheels on Adaptive Joins and blogging about it as I go. Stay tuned!
Thanks for reading!
Brent says: when I first heard about Adaptive Joins, I thought, “This is amazing!” but I still had no idea about how complex it would get. Reading Erik’s upcoming posts, I’m even more excited about the potential this holds for down the road. Granted, it’s only for columnstore indexes right now, but still, this is gonna make 2017 a heck of a release for performance tuners.