asked on When is Multi-Valued UDF faster than inline UDF?
Hi,
I have rewritten an UDF from inline to multi-valued UDF and was able to reduce the query time from ~20seconds down to ~2seconds. All the literature indicates that inline are generally faster than multi valued UDF's.
The original inline query looked something like the following:
create function udf_inline
(
@p1 int,
@p2 datetime
)
returns table
as
return
select
*
from
(
select
*
from
(
select
*
from
tableA
where
col1 = @p1
and col2 = @p2
)
)
I have rewritten the query to use multi lined UDF
CREATE FUNCTION dbo.MV_UDF
(
@p1 INT,
@p2 DATETIME
)
RETURNS @myTable TABLE
(
colA varchar(50),
colB varchar(50),
etc...
)
AS
BEGIN
insert into @myTable
select
*
from
(
select
*
from
(
select
*
from
tableA
where
col1 = @p1
and col2 = @p2
)
)
RETURN
Why the multi-valued UDF runs faster I do not know. Anyone can provide some insight?
thanks
I have rewritten an UDF from inline to multi-valued UDF and was able to reduce the query time from ~20seconds down to ~2seconds. All the literature indicates that inline are generally faster than multi valued UDF's.
The original inline query looked something like the following:
create function udf_inline
(
@p1 int,
@p2 datetime
)
returns table
as
return
select
*
from
(
select
*
from
(
select
*
from
tableA
where
col1 = @p1
and col2 = @p2
)
)
I have rewritten the query to use multi lined UDF
CREATE FUNCTION dbo.MV_UDF
(
@p1 INT,
@p2 DATETIME
)
RETURNS @myTable TABLE
(
colA varchar(50),
colB varchar(50),
etc...
)
AS
BEGIN
insert into @myTable
select
*
from
(
select
*
from
(
select
*
from
tableA
where
col1 = @p1
and col2 = @p2
)
)
RETURN
Why the multi-valued UDF runs faster I do not know. Anyone can provide some insight?
thanks
Microsoft SQL Server 2008
Last Comment
yechan
Maintenance plan will learn you more about the different usage.
Actually your "inline" udf_inline function is NOT a inline but still a table function if you look at its definition (below) and yours is fater as you work with explicit @table in return and most likely better optimized. but in my opinion you can still get rid of one unnecessary SELECT * in your function code.
create function udf_inline
(
@p1 int,
@p2 datetime
)
returns table
as
create function udf_inline
(
@p1 int,
@p2 datetime
)
returns table
as
Also it may faster because the data was cached from running prior "inline" code so it just look faster but it may be not for the first time you run it with SQL cold cache.
And BTW....why not just a regular SQL stored proc if all you need a the record set returned byt the SQL code? I would use a table UDF if I need to join that record set but otherwise I would use from all aspects including performance just a regular SPROC like:
CREATE PROCEDURE dbo.My_SPROC
(
@p1 INT,
@p2 DATETIME
)
AS
SET NOCOUNT ON;
select * from tableA
where col1 = @p1 and col2 = @p2
RETURN
GO
CREATE PROCEDURE dbo.My_SPROC
(
@p1 INT,
@p2 DATETIME
)
AS
SET NOCOUNT ON;
select * from tableA
where col1 = @p1 and col2 = @p2
RETURN
GO
ASKER
Hi lcohan
Not sure why you would say that my inline function is not an inline function but is instead an Multi-Statement Table-Valued function.
Would love to convert it to a stored procedure but that function is being dynamically called from a web page but at this point, not sure if it is worth the trouble doing this. At least not at the moent.
Not sure why you would say that my inline function is not an inline function but is instead an Multi-Statement Table-Valued function.
Would love to convert it to a stored procedure but that function is being dynamically called from a web page but at this point, not sure if it is worth the trouble doing this. At least not at the moent.
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
Sorry for getting back so late. Turns out that the web application wraps sql statements around sp_executesql whereas in SSMS I do not use sp_executesql. This defn. changed things and probably explains the behavior. Thank you for all the feedback.