With SQL Server 2008 R2 running out of support this July, we’re experimenting with SQL Server 2019
Spoiler alert: It’s awesome. The performance, scalability and availability features of SQL Server offers new productivity benefits that are going to change the life for the DBA. As performance tuning experts, we tested several functions in SQL Server 2019 – scalar functions, multi-statement table valued functions, and Inline table valued functions.
Learn how to track performance and work with these SQL Server features below.
- Automatic Tuning: Scalar Functions with SQL Server 2019
- The Silent Performance Killer: Scalar Functions vs Table Value Functions
- What is difference between a Multi-statement Table Valued Function and a Inline Table Valued Function?
- Multi-statement table valued function vs inline table valued function
Automatic Tuning: Scalar Functions with SQL Server 2019
Learn how SQL Server 2019 automatically makes your scalar functions run faster by converting row by row processing to set based processing without any code changes.
The Silent Performance Killer: Scalar Functions vs Table Value Functions
Learn how scalar functions cause row by row processing which causes performance to get magnitudes worse when processing more data. Learn how table value functions use set based logic and run faster.
Want access to the source code? Access now
What is difference between a Multi-statement Table Valued Function and a Inline Table Valued Function?
Learn the core fundamental differences between a Multi-Statement Table-Valued Function and an Inline-Table Valued Function. In the next the video we will focus on performance differences.
Multi-statement table valued function vs inline table valued function
Learn how SQL Server 2017 Automatically converts multi-statement table value functions to inline table valued functions without any code changes by you!
Got Performance Tuning Questions? Ask them for FREE!
The Monitoring Game Changer
With SQL 2017 and also SSMS 18 RC1 you can now get access to your wait statistics for each execution plan per time interval used by query store. This is a game changer to see why my query is running lower than normal.
