Joining on a TVF that builds a temp table is much faster than straight clause. Why is this?

Question

We were optimising a query that looked to be poorly designed. There was a join to a multi-line table valued function, that could easily have been an inline function, so we updated it.. but the query became much slower. The multi-line function was returning a temp table with a single column as the primary key, while the inline TVF just returned a straight single column table.

Doing a bit of R&D, we found that there were big performance gains using joined multi-line TVFs as clauses. The following example can be run against any DB, preferably with a long history of object updates. The first query is what we thought would be the best design, but it is the second that performs far better (typically 20x faster). This was actually query cost, not speed

create function udf_ObjectsModifiedBetweenDates
(
    @DateFrom datetime,
    @Dateto datetime
)
returns @t table(object_id int primary key)
as
begin
insert into @t
(
    object_id
)
select object_id
from sys.objects 
where modify_date between @DateFrom and @Dateto
return
end

GO

declare @datefrom datetime = '2017-05-01' --Please adjust these dates to get good sample
declare @dateto datetime = '2018-08-02'

--slow
select object_id, parent_object_id, is_ms_shipped
from sys.objects
where modify_date between @datefrom and @dateto option (recompile)

--fast
select o.object_id, o.parent_object_id, o.is_ms_shipped
from sys.objects o
inner join udf_ObjectsModifiedBetweenDates(@datefrom, @dateto) ombd on o.object_id = ombd.object_id option (recompile)

The function and query is similar to the one that we were dealing with on our system, but here we have substituted a system table for the user table. We have tried the same thing on other user tables, again getting huge benefit from the MTVF. The execution plans show that there is a clustered index scan on the TVF on the faster query. Can anyone explain what is happening and if this is a viable method to improve query performance?

Answer 1

It seems you are misinterpreting "Query cost (relative to the batch)" for "Query cost (how long the query will take to run)" in the execution plan. The cost of a query can have very little to do with how efficient or fast a query is.

I ran this query (changing the dates) with both the following on:

SET STATISTICS IO ON;
SET STATISTICS TIME ON;

For the query you labeled as "slow" (the one without the UDF) the result was:

The "slow" one

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.
SQL Server parse and compile time: 
   CPU time = 8 ms, elapsed time = 8 ms.

(19305 rows affected)
Table 'sysschobjs'. Scan count 1, logical reads 379, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

(1 row affected)

 SQL Server Execution Times:
   CPU time = 62 ms,  elapsed time = 61 ms.

And for the one you labeled "fast" (The UDF) the output was:

The "fast" one

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 7 ms.

(19305 rows affected)
Table 'sysschobjs'. Scan count 0, logical reads 38610, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table '#B1BBD6DD'. Scan count 1, logical reads 34, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

(1 row affected)

 SQL Server Execution Times:
   CPU time = 266 ms,  elapsed time = 329 ms.

As you can see by these stats, the non-UDF version was by far the winner. The execution time for the non-UDF was more than 5 times faster, however, the IO for the UDF query was insane (over 1,000 times more reads).

In all honesty, Multi-line Table-Value Functions are more than often performance killers. Of the 3 types of functions (inline table-value, Scalar value and multi-line table-value) they are probably the slowest, where as inline are by far often the faster. I have heard, on the rumour mill, that scalar functions are "better" in SQL Server 2019, however, I haven't tested myself nor have i actually seen any real evidence yet; just in conversation.