Try creating an inline function oriented to the table. Example:
CREATE FUNCTION dbo.fxnExample (@Parameter1 INTEGER) RETURNS TABLE AS RETURN ( SELECT Field1, Field2 FROM SomeTable WHERE Field3 = @Parameter1 )
If you look at the execution plan for SELECT, you wonβt see a mention of the function at all, and you really just show you what base tables are being requested. This is good, as it means that statistics on the base tables will be used when creating the execution plan for the query.
The thing to avoid is a function with many statements, since basic table statistics will not be used and may lead to poor performance due to a poor execution plan.
An example of what to avoid :
CREATE FUNCTION dbo.fxnExample (@Parameter1 INTEGER) RETURNS @Results TABLE(Field1 VARCHAR(10), Field2 VARCHAR(10)) AS BEGIN INSERT @Results SELECT Field1, Field2 FROM SomeTable WHERE Field3 = @Parameter1 RETURN END
A subtle difference, but with potentially large differences in performance when a function is used in a request.
AdaTheDev Dec 21 '10 at 10:54 2010-12-21 10:54
source share