Can any body help me in understanding if the execution plan for functions cached in SQL server?
Any online resource for this?
The Estimated Execution Plan is the compiled plan, as produced by the Query Optimizer based on estimations. This is the query plan that is stored in the plan cache.
SQL Server caches the plans for ad hoc Transact-SQL statements for later reuse if the identical Transact-SQL statement is later executed. User-parameterized queries (even if not explicitly prepared) are also monitored as Prepared SQL Plans. Query plans generated by creating a stored procedure, function, or trigger.
In the Context Menu of the Query Window, you will find a menu on the toolbar in SQL Server Management Studio with the name “Display Estimated Execution Plan”. It will work the same way as the above step will do. It will display the Estimated Execution Plan.
When a stored procedure is executed it is optimized and compiled and the query plan is placed in procedure cache. Procedures remain in cache for other users, as long as there is space. Procedures are removed using the least recently used (LRU) algorithm.
The accepted answer is inaccurate / misleading, primarily due to the referenced quote being too vague with regards to the term "user-defined functions".
There are several different types of User-Defined Functions in Microsoft SQL Server, and they are treated differently:
Multi-statement TVFs:
These are treated like Stored Procedures. The query that executes them only shows the reference to their name, not to any of their definition. They show up in sys.dm_exec_cached_plans
with a cacheobjtype
of "Compiled Plan" and an objtype
of "Proc". Any input parameter values are also stored with the plan, hence Multi-statement TVFs are subject to parameter-sniffing issues.
Inline TVFs (iTVFs):
These are treated like Views. The query that executes them incorporates their definition. They show up in sys.dm_exec_cached_plans
with a cacheobjtype
of "Parse Tree" and an objtype
of "View". Input parameter values are not stored with the plan, hence Inline TVFs are not subject to parameter-sniffing issues.
Scalar UDFs:
These are treated like Stored Procedures. The query that executes them only shows the reference to their name, not to any of their definition. They show up in sys.dm_exec_cached_plans
with a cacheobjtype
of "Compiled Plan" and an objtype
of "Proc". Any input parameter values are also stored with the plan, hence Scalar UDFs are subject to parameter-sniffing issues. Also, unlike the two types of TVFs noted above, but like regular Stored Procedures, you can force recompilation of the execution plan using the WITH RECOMPILE
option when executing via EXEC[UTE]
instead of SELECT
or SET
.
SQLCLR objects:
These are treated more like client / app code. The query that executes them only shows the reference to their name, not to any of their definition. They show up in sys.dm_exec_cached_plans
with a cacheobjtype
of "CLR Compiled Func" or "CLR Compiled Proc", and an objtype
of "Proc". But, unlike Multi-statement TVFs and Scalar UDFs, they do not have a definition and so do not have an associated query plan. However, any adhoc queries (not stored procedure calls) that they execute show up in sys.dm_exec_cached_plans
with a cacheobjtype
of "Compiled Plan" and an objtype
of "Prepared". Any of these adhoc queries, if parameterized, should be storing the initial input parameter values with the prepared plan, and would hence be subject to parameter-sniffing issues.
For more details on object caching, please see the MSDN page on Caching Mechanisms.
Yes they do go in the execution plan cache.
The sys.dm_exec_query_plan DMV will show a plan for given plan handle. Quote from there:
Query plans for various types of Transact-SQL batches, such as ad hoc batches, stored procedures, and user-defined functions, are cached in an area of memory called the plan cache. Each cached query plan is identified by a unique identifier called a plan handle. You can specify this plan handle with the sys.dm_exec_query_plan dynamic management view to retrieve the execution plan for a particular Transact-SQL query or batch.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With