Do user defined data types always cause implicit conversion to occur when fields of those UDDTs are used as predicates?

Question

I have a database (from a vendor application) that for some unknown reason has a UDDT on almost every column, even when the UDDT is logically the same as the underlying type it implements. E.g. a column in this database might be of UDDT bTinyInt(TinyInt).

Two tables in this database have columns that share the same exact UDDT. E.g. TableA.Field1 is of type bVarchar(VARCHAR(10)) and TableB.Field2 is also bVarchar(VARCHAR(10)).

When I join these two tables together by the aforementioned fields, I notice a warning in the execution plan stating a Cardinality Issue because these fields are being implicitly converted to VARCHAR(MAX).

Is it always the case that UDDTs get implicitly converted when used as predicates, even when comparing the same UDDT?

Also not sure if it matters as well, but the database these two tables belong to is of collation Latin1_General_BIN.

Answer 1

I can't reproduce any warnings or performance differences in this scenario, even when joining bVarchar to varchar(10). EG

create database tt 

alter database tt collate Latin1_General_BIN
use tt 
go
create type bVarchar from varchar(10)

create table a(id int primary key identity, b bVarchar, c varchar(10));
create table b(id int primary key identity, b bVarchar, c varchar(10));

with q as
(
  select top 1000000 row_number() over (order by (select null)) i
  from sys.messages, sys.objects 
)
insert into a (b,c) 
select concat(i%10000,'abc'), concat(i%10000,'abc')
from q;  

with q as
(
  select top 1000000 row_number() over (order by (select null)) i
  from sys.messages, sys.objects 
)
insert into b (b,c) 
select concat(i%10000,'abc'), concat(i%10000,'abc')
from q;  

go


set statistics time on
set statistics io on

select count(*)
from a
join b 
  on a.b = b.b

select count(*)
from a
join b 
  on a.c = b.c

select count(*)
from a
join b 
  on a.b = b.c

set statistics time off
set statistics io off

outputs

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

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

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

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

(1 row affected)
Table 'a'. Scan count 9, logical reads 4125, physical reads 0, page server reads 0, read-ahead reads 3510, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.
Table 'b'. Scan count 9, logical reads 4125, physical reads 0, page server reads 0, read-ahead reads 2656, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, page server reads 0, read-ahead reads 0, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.

(1 row affected)

 SQL Server Execution Times:
   CPU time = 268 ms,  elapsed time = 117 ms.

(1 row affected)
Table 'a'. Scan count 9, logical reads 4125, physical reads 0, page server reads 0, read-ahead reads 0, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.
Table 'b'. Scan count 9, logical reads 4125, physical reads 0, page server reads 0, read-ahead reads 0, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, page server reads 0, read-ahead reads 0, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.

(1 row affected)

 SQL Server Execution Times:
   CPU time = 297 ms,  elapsed time = 184 ms.

(1 row affected)
Table 'a'. Scan count 9, logical reads 4125, physical reads 0, page server reads 0, read-ahead reads 0, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.
Table 'b'. Scan count 9, logical reads 4125, physical reads 0, page server reads 0, read-ahead reads 0, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, page server reads 0, read-ahead reads 0, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.

(1 row affected)

 SQL Server Execution Times:
   CPU time = 280 ms,  elapsed time = 111 ms.

Completion time: 2020-10-17T09:56:35.6734439-05:00

Answer 2

There is no performance issue with UDDTs . There is no Warning message when UDDTs is use in Predicate.

Reason :

select * from sys.columns

In this query notice the system_type_id & user_type_id.Sql optmizer already know and uses system Data Type.