Improving the Performance of Functions Eric Freeman Lead BI Architect @ John Burns Real Estate Consulting Over 15 Years Experience

Agenda- Overview Brief History Limitations Function Types Functions with Bad Performance Refactoring Function UDF Auto Inline

Why we use Functions Modular Reusable Cleaner queries In most coding languages, functions are often-used blocks of code that can be reused from multiple locations, leading to less code – and cleaner code. SQL Server also lets us create functions that can be used the same way. They are reusable blocks of code that can be called from multiple locations.

Function Origins Functional programming has its origins in lambda calculus , a formal system developed in the 1930s to investigate computability SQL Server 2000- Microsoft introduced the concept of User-Defined Functions that allow you to define your own T-SQL functions that can accept zero or more parameters and return a single scalar data value or a table data type.

UDF Limitations Can not be used to perform actions that modify the database state Can not contain an OUTPUT INTO clause that has a table as its target Can not return multiple result sets Can not call a stored procedure* Can not use dynamic SQL or temp tables. Table variables are allowed Can not use SET statements (ex. SET ROWCOUNT) Can not use The FOR XML clause Error handling is restricted and does not support TRY...CATCH, @ERROR or RAISERROR User-defined functions can be nested; that is, one user-defined function can call another. The nesting level is incremented when the called function starts execution, and decremented when the called function finishes execution. User-defined functions can be nested up to 32 levels. Exceeding the maximum levels of nesting causes the whole calling function chain to fail. Any reference to managed code from a Transact-SQL user-defined function counts as one level against the 32-level nesting limit. Methods invoked from within managed code do not count against this limit.

Function Types Scalar- Returns a single value Multi-Statement Table Value Function- Returns table Inline Table Value Function- Returns table

Scalar Function Syntax CREATE [ OR ALTER ] FUNCTION [ schema_name. ] function_name ( [ { @parameter_name [ AS ][ type_schema_name. ] parameter_data_type [ = default ] [ READONLY ] } [ ,...n ] ] ) RETURNS return_data_type [ WITH <function_option> [ ,...n ] ] [ AS ] BEGIN function_body RETURN scalar_expression END [ ; ]

Scalar Function Syntax CREATE FUNCTION [dbo].function_name (@parameter AS int) RETURNS int --WITH SCHEMABINDING, ... AS BEGIN --function_body RETURN 1 --value END

Multi-Statement TVF Syntax CREATE [ OR ALTER ] FUNCTION [ schema_name. ] function_name ( [ { @parameter_name [ AS ] [ type_schema_name. ] parameter_data_type [ = default ] [READONLY] } [ ,...n ] ] ) RETURNS @return_variable TABLE <table_type_definition> [ WITH <function_option> [ ,...n ] ] [ AS ] BEGIN function_body RETURN END [ ; ]

Multi-Statement TVF Syntax CREATE FUNCTION [dbo].function_name (@parameter AS int) RETURNS @return_variable TABLE (a int)--<table_type_definition> --WITH SCHEMABINDING, ... AS BEGIN --function_body RETURN END

Inline TVF Syntax CREATE [ OR ALTER ] FUNCTION [ schema_name. ] function_name ( [ { @parameter_name [ AS ] [ type_schema_name. ] parameter_data_type [ = default ] [ READONLY ] } [ ,...n ] ] ) RETURNS TABLE [ WITH <function_option> [ ,...n ] ] [ AS ] RETURN [ ( ] select_stmt [ ) ] [ ; ]

Inline TVF Syntax CREATE FUNCTION [dbo].function_name (@parameter AS int) RETURNS TABLE --WITH SCHEMABINDING, ... AS RETURN (select 1 as colName)

Demo 1 Create & Demo Functions

Functions Have Purpose As we looked at in the prior demo, functions have their place in SQL and should not be set aside Some companies have outright bans on UDF’s due to having prior, unresolved, issues with them.

Demo 2 Performance- Why is that query taking so long?

Good, not Great User defined functions give you great benefits in terms of encapsulation and code reusability Unfortunately, when you invoke a scalar UDF as part of a query and pass the function a column from the table as input, the function is invoked separately for each row This causes queries that could logically run fast, run significantly slower

Demo 3 What can we do to “make functions great again”?

Scalar UDF Inlining SQL 2019- Removing the ban on Scalar Functions The goal of the Scalar UDF inlining feature is to improve performance of queries that invoke scalar UDFs, where UDF execution is the main bottleneck.

Is my UDF inlineable? The sys.sql_modules catalog view includes a property called “is_inlineable”, which indicates whether a UDF is inlineable or not A value of 1 indicates that it is inlineable, and 0 indicates otherwise This property will also have a value of 1 for inline table-valued functions, since they are inlineable by definition.

Inlineable Checklist DECLARE, SET: Variable declaration and assignments. SELECT: SQL query with single/multiple variable assignments*. IF/ELSE: Branching with arbitrary levels of nesting. RETURN: Single or multiple return statements. UDF: Nested/recursive function calls**. Others: Relational operations such as EXISTS, ISNULL. The UDF does not invoke any intrinsic function that is either time-dependent (such as GETDATE()) or has side effects*** (such as NEWSEQUENTIALID()). The UDF uses the EXECUTE AS CALLER clause (the default behavior if the EXECUTE AS clause is not specified). The UDF does not reference table variables or table-valued parameters. The query invoking a scalar UDF does not reference a scalar UDF call in its GROUP BY clause.

Inlineable Checklist The UDF is not natively compiled (interop is supported). The UDF is not used in a computed column or a check constraint definition. The UDF does not reference user-defined types. There are no signatures added to the UDF. The UDF is not a partition function. *SELECT with variable accumulation/aggregation (for example, SELECT @val += col1 FROM table1) is not supported for inlining. **Recursive UDFs will be inlined to a certain depth only. ***Intrinsic functions whose results depend upon the current system time are time-dependent. An intrinsic function that may update some internal global state is an example of a function with side effects. Such functions return different results each time they are called, based on the internal state.

Summary How Scalar functions can destroy performance How Inline Table Valued Functions work w/ the Query Engine How SQL 2019 improves Scalar functions by making them inline automagically

Questions