You are on page 1of 19

SQL Server 2017

Adaptive Query Processing


Hi, Im
Cristian.
Principal @ Esential Training
http://about.me/CristianLefter
AGENDA
Query Processing and Cardinality
1 Estimation
Interleaved Execution for Multi-
2 Statement Table Valued Functions

3 Batch Mode Adaptive Memory Grant


Feedback
4 Batch Mode Adaptive Joins
1
Query Processing
&
Cardinality Estimation
Query Performance depends on Query Plan quality which in turn is heavily
dependent on Cardinality Estimation (CE)
Query Plan Quality
meansgood decisions about the order of
operations as well as of the physical
algorithm selection
is heavily dependent on Cardinality
Estimation (CE)

Cardinality Estimation is a process that uses


a combination of statistical techniques and
assumptions to provide an estimated number of
rows to the optimization process. Query Plan
Slow query Reduced throughput
response due to and concurrency
bad plans

Excessive T-SQL
resource refactoring for
utilization (CPU, off-model
Memory, IO) statements

Risk of
misestimating
Cardinality
Estimation and
Plan Quality
2

Interleaved Execution
Interleaved
Execution
During the optimization phase if a
multi-statement table valued
functions (MSTVFs) is encountered,
the optimization is paused, the
applicable subtree will be executed,
accurate cardinality estimates will
be captured and then resume
optimization for downstream
operations
Example Not
using
Interleaved
Execution
Example
Using
Interleaved
Execution
3

Batch Mode Adaptive


Memory Grant Feedback
Batch Mode
Adaptive
Memory Grant
Feedback
Adjust memory grants based on
execution feedback
Remove spills and Improve
concurrency for repeating queries

How does batch mode adaptive memory grant feedback work?


For excessive grants, if the granted memory is more than two times the size of the
actual used memory, memory grant feedback will recalculate the memory grant and
update the cached plan. Plans with memory grants under 1MB will not be recalculated for
overages.
For insufficiently sized memory grantsthat result in a spill to disk for batch mode
operators, memory grant feedback will trigger a recalculation of the memory grant. Spill
events are reported to memory grant feedback and can be surfaced via
4

Batch Mode Adaptive Joins


Batch Mode
Adaptive Joins
How it works at a high level:
If the row count of the build join input is small
enough that a nested loop join would be more
optimal than a hash join, we will switch to a nested
loop algorithm.
If the build join input exceeds a specific row count
threshold, no switch occurs and we will continue
with a hash join.
The batch mode adaptive joins feature enables the choice of a
hash join or nested loop join method to be deferred until the
after the first input has been scanned. The Query Processing
team introduced a new Adaptive Join operator. This
operator defines a threshold that will be used to decide when
we will switch to a nested loop plan.
SELECT [fo].[Order Key], [si].[Lead Time Days], [fo].[Quantity]
FROM [Fact].[Order] AS [fo]
JOIN [Dimension].[Stock Item] AS [si]
ON [fo].[Stock Item Key] = [si].[Stock Item Key]
WHERE [fo].[Quantity] = 360; Query Plan Example
SELECT [fo].[Order Key], [si].[Lead Time Days], [fo].[Quantity]
FROM [Fact].[Order] AS [fo]
JOIN [Dimension].[Stock Item] AS [si]
ON [fo].[Stock Item Key] = [si].[Stock Item Key]
WHERE [fo].[Quantity] = 361; Query Plan Example
Thank You!
If you enjoyed this presentation, please let me know

http://speakerscore.com/cristian170506

@xmldeveloper

You might also like