Craig Freedman's SQL Server Blog : Conversions

Implicit Conversions

craigfr — Thu, 05 Jun 2008 20:15:00 GMT

In my last couple of posts, I wrote about how explicit conversions can lead to errors. In this post, I'm going to take a look at some issues involving implicit conversions. SQL Server adds implicit conversions whenever you mix columns, variables, and/or parameters with different (but compatible) data types in a single expression. For example, if you try to compare INT and FLOAT columns, the INT must be converted to a FLOAT. If you write "C_INT = C_FLOAT", SQL Server rewrites this expressions as "CONVERT(FLOAT,C_INT) = C_FLOAT".

When performing implicit conversions, SQL Server will try to choose the conversion that is least likely either to fail due to an overflow or to lose precision. For example, a SMALLINT will be converted to an INT since all SMALLINTs can be converted to INTs without any data loss. On the other hand, an INT will be converted to a REAL since all INTs can be converted to REALs but not vice-versa. However, the conversion is potentially lossy since some INTs contain more digits than can be represented by a REAL.

Note that some data types can only be combined in a single expression by using an explicit conversion and that some data types are not compatible at all with or without an explicit conversion. This Books Online page includes a compatibility matrix showing all of the possible data type combinations. For the remainder of this post, I'm going to focus only on implicit conversions.

To get started, I'd like to show an example that did not work so well on SQL Server 2000:

CREATE TABLE T (C INT)
CREATE UNIQUE CLUSTERED INDEX TC ON T(C)

INSERT T VALUES (1000000000)
INSERT T VALUES (1000000001)

First, let's consider a query that uses a clustered index scan:

DECLARE @V REAL
SET @V = 1E9
SELECT * FROM T WITH (INDEX(0)) WHERE C = @V

C           
----------- 
1000000000
1000000001

At first glance, this may seem like an incorrect result. The second row does not appear to match the predicate. However, if we check the plan, we see that SQL added an implicit convert to the predicate:

|--Clustered Index Scan(OBJECT:([T].[TC]), WHERE:(Convert([T].[C])=[@V]))

Moreover, if we check the results of the conversion, we can see that it is lossy. Both INTs convert to the same REAL value. The above results now make more sense:

SELECT *, CONVERT(REAL,C) REAL_C FROM T

C           REAL_C                   
----------- ------------------------ 
1000000000  1.0E+9
1000000001  1.0E+9

Now, let's consider the same query with a clustered index seek:

DECLARE @V REAL
SET @V = 1E9
SELECT * FROM T WITH (INDEX(1)) WHERE C = @V

C           
----------- 
1000000000

Hold it! What happened to the second row? Let's check the plan:

|--Nested Loops(Inner Join, OUTER REFERENCES:([Expr1002], [Expr1003], [Expr1004]))
       |--Compute Scalar(DEFINE:([Expr1002]=Convert([@V])-1, [Expr1003]=Convert([@V])+1, [Expr1004]=If (Convert([@V])-1=NULL) then 0 else 6|If (Convert([@V])+1=NULL) then 0 else 10))
       |    |--Constant Scan
       |--Clustered Index Seek(OBJECT:([T].[TC]), SEEK:([T].[C] > [Expr1002] AND [T].[C] < [Expr1003]), WHERE:(Convert([T].[C])=[@V]) ORDERED FORWARD)

This plan looks rather complicated, but aside from unfortunately getting a wrong answer (at least according to the conversion semantics we just discussed), it is really quite simple. To perform an index seek, SQL Server must have key values that match the data type stored in the index. SQL Server cannot perform an index seek on an INT index using a REAL key. So, SQL Server must convert the REAL variable to an INT. Because, as we've already seen, conversions can be lossy, SQL Server also expands the range of values returned by the index seek by subtracting and adding one to the result of the conversion. Basically, after substituting the value of the parameter, this plan is the same as running the following query:

SELECT * FROM T WHERE (C > 999999999 AND C < 1000000001) AND CONVERT(REAL,C) = 1E9

Notice that the original predicate with the convert is retained in case the index seek returns too many rows and some must be filtered out. In most cases, this algorithm works just fine; I've deliberately selected a scenario that does not work so well. In addition to potentially omitting results, this algorithm may also harm performance. For instance, consider this example:

CREATE TABLE T (C NUMERIC(12,4))
CREATE UNIQUE CLUSTERED INDEX TC ON T(C)

INSERT T VALUES (0.0001)
INSERT T VALUES (0.0002)
INSERT T VALUES (0.0003)
...

DECLARE @P REAL
SET @P = 1.0000
SELECT * FROM T WITH (INDEX(1)) WHERE C = @P

Suppose that table T includes many values in the range 0.0000 to 2.0000. In this example, the conversion is lossless. Only rows with the value 1.0000 should be returned. Unfortunately, the index seek still returns all of the rows in the range and the filter with the convert discards all of them except for those with the value 1.0000.

Now let's see how SQL Server 2005 (and 2008) handle these same queries. Let's start with the clustered index scan:

DECLARE @P REAL
SET @P = 1E9
SELECT * FROM T WITH (INDEX(0)) WHERE C = @P

|--Clustered Index Scan(OBJECT:([T].[TC]), WHERE:(CONVERT_IMPLICIT(real(24),[T].[C],0)=[@P]))

This is the same plan that we got from SQL Server 2000 and we get the same result (both rows). The only difference is that SQL Server 2005 indicates that the convert is implicit and provides the type of the conversion. Next let's try the clustered index seek:

DECLARE @P REAL
SET @P = 1E9
SELECT * FROM T WITH (INDEX(1)) WHERE C = @P

|--Nested Loops(Inner Join, OUTER REFERENCES:([Expr1005], [Expr1006], [Expr1004]))
       |--Compute Scalar(DEFINE:(([Expr1005],[Expr1006],[Expr1004])=GetRangeThroughConvert([@P],[@P],(62))))
       |    |--Constant Scan
       |--Clustered Index Seek(OBJECT:([T].[TC]), SEEK:([T].[C] > [Expr1005] AND [T].[C] < [Expr1006]), WHERE:(CONVERT_IMPLICIT(real(24),[T].[C],0)=[@P]) ORDERED FORWARD)

This plan is similar to the SQL Server 2000 plan with one key difference. The conversion of the seek key from REAL to INT is performed by an internal function GetRangeThroughConvert which correctly determines the exact range of values to seek. A little experimentation will show that, in this example, the range works out to all values between 999,999,968 and 1,000,000,479. On the other hand, for the example with the numeric column, the "range" works out to exactly 1.0000. This solution is both more accurate and more efficient than the SQL Server 2000 algorithm.

Finally, let's take a look at the performance implications of the new plan:

CREATE TABLE T1 (C_INT INT, C_REAL REAL)
CREATE CLUSTERED INDEX T1_C_REAL ON T1(C_REAL)

CREATE TABLE T2 (C_INT INT, C_REAL REAL)
CREATE CLUSTERED INDEX T2_C_INT ON T2(C_INT)

SET NOCOUNT ON
DECLARE @I INT
SET @I = 0
WHILE @I < 100000
BEGIN
    INSERT T1 VALUES (@I, @I)
    INSERT T2 VALUES (@I, @I)
    SET @I = @I + 1
END

Here are three join plans. I'm using a join hint to ensure that I do not get a hash join which uses a completely different algorithm. I'm using COUNT(*) to eliminate the overhead of transferring output rows to the client and an OPTION hint to avoid parallelism. The first plan joins the two INT columns. The second plan joins the two REAL columns. The third plan joins the INT and REAL columns and uses the same algorithm with the GetRangeThroughConvert function as the simpler query above.

SELECT COUNT(*)
FROM T1 INNER LOOP JOIN T2 ON T1.C_INT = T2.C_INT
OPTION(MAXDOP 1)

|--Compute Scalar(DEFINE:([Expr1008]=CONVERT_IMPLICIT(int,[Expr1012],0)))
       |--Stream Aggregate(DEFINE:([Expr1012]=Count(*)))
            |--Nested Loops(Inner Join, OUTER REFERENCES:([T1].[C_INT], [Expr1011]) WITH UNORDERED PREFETCH)
                 |--Clustered Index Scan(OBJECT:([T1].[T1_C_REAL]))
                 |--Clustered Index Seek(OBJECT:([T2].[T2_C_INT]), SEEK:([T2].[C_INT]=[T1].[C_INT]) ORDERED FORWARD)

SELECT COUNT(*)
FROM T2 INNER LOOP JOIN T1 ON T2.C_REAL = T1.C_REAL
OPTION(MAXDOP 1)

|--Compute Scalar(DEFINE:([Expr1008]=CONVERT_IMPLICIT(int,[Expr1012],0)))
       |--Stream Aggregate(DEFINE:([Expr1012]=Count(*)))
            |--Nested Loops(Inner Join, OUTER REFERENCES:([T2].[C_REAL], [Expr1011]) WITH UNORDERED PREFETCH)
                 |--Clustered Index Scan(OBJECT:([T2].[T2_C_INT]))
                 |--Clustered Index Seek(OBJECT:([T1].[T1_C_REAL]), SEEK:([T1].[C_REAL]=[T2].[C_REAL]) ORDERED FORWARD)

SELECT COUNT(*)
FROM T1 INNER LOOP JOIN T2 ON T1.C_REAL = T2.C_INT
OPTION(MAXDOP 1)

|--Compute Scalar(DEFINE:([Expr1008]=CONVERT_IMPLICIT(int,[Expr1014],0)))
       |--Stream Aggregate(DEFINE:([Expr1014]=Count(*)))
            |--Nested Loops(Inner Join, OUTER REFERENCES:([T1].[C_REAL]))
                 |--Clustered Index Scan(OBJECT:([T1].[T1_C_REAL]))
                 |--Nested Loops(Inner Join, OUTER REFERENCES:([Expr1012], [Expr1013], [Expr1011]))
                      |--Compute Scalar(DEFINE:(([Expr1012],[Expr1013],[Expr1011])=GetRangeThroughConvert([T1].[C_REAL],[T1].[C_REAL],(62))))
                      |    |--Constant Scan
                      |--Clustered Index Seek(OBJECT:([T2].[T2_C_INT]), SEEK:([T2].[C_INT] > [Expr1012] AND [T2].[C_INT] < [Expr1013]), WHERE:([T1].[C_REAL]=CONVERT_IMPLICIT(real(24),[T2].[C_INT],0)) ORDERED FORWARD)

I measured the times using SET STATISTICS TIME ON. Here are the results I got on my system:

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

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

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

Notice that each of first two queries with the joins on the matching types complete in 740ms while the third query with the join on the mismatched types takes more than twice as long at 1600ms! The moral of this story? Try to stick to matching types whenever possible.

Conversion and Arithmetic Errors: Change between SQL Server 2000 and 2005

craigfr — Tue, 06 May 2008 21:54:00 GMT

In this post from last week, I gave an example of a query with a conversion where the optimizer pushes the conversion below a join. The result is that the conversion may be run on rows that do not join which could lead to avoidable failures. I ran this query on SQL Server 2005. After I published that post, a reader pointed out to me that my example query generates a different plan on SQL Server 2000:

CREATE TABLE T1 (A INT, B CHAR(8))
INSERT T1 VALUES (0, '0')
INSERT T1 VALUES (1, '1')
INSERT T1 VALUES (99, 'Error')

CREATE TABLE T2 (X INT)
INSERT T2 VALUES (1)
INSERT T2 VALUES (2)
INSERT T2 VALUES (3)
INSERT T2 VALUES (4)
INSERT T2 VALUES (5)

SELECT T1.A, CONVERT(INT, T1.B) AS B_INT
FROM T1 JOIN T2 ON T1.A = T2.X

Here is the SQL Server 2000 plan:

|--Compute Scalar(DEFINE:([Expr1004]=Convert([T1].[B])))
       |--Hash Match(Inner Join, HASH:([T1].[A])=([T2].[X]), RESIDUAL:([T2].[X]=[T1].[A]))
            |--Table Scan(OBJECT:([T1]))
            |--Table Scan(OBJECT:([T2]))

And here is the SQL Server 2005 plan:

|--Hash Match(Inner Join, HASH:([T1].[A])=([T2].[X]), RESIDUAL:([T2].[X]=[T1].[A]))
       |--Compute Scalar(DEFINE:([Expr1008]=CONVERT(int,[T1].[B],0)))
       |    |--Table Scan(OBJECT:([T1]))
       |--Table Scan(OBJECT:([T2]))

The result is that the SQL Server 2000 plan runs without any errors - the "bad" row is filtered out by the join - while the SQL Server 2005 plan fails when it tries to convert the "bad" row. It turns out that this change in behavior is documented in this Books Online entry under the Transact-SQL section and "Expressions in queries" feature. This entry states that queries that worked on SQL Server 2000 could fail on SQL Server 2005. It also states that the change enables two benefits: "the ability to match indexes on computed columns" and "the prevention of redundant computation of expression results." Let's investigate these two benefits.

To understand the first benefit ("the ability to match indexes on computed columns"), suppose we create a new table with a computed column that matches the conversion in our query and then create an index on that computed column:

CREATE TABLE T3 (A INT, B CHAR(8), C AS CONVERT(INT, B)
CREATE INDEX T3C ON T3 (C, A)

INSERT T3 VALUES (0, '0')
INSERT T3 VALUES (1, '1')

This computed column is sometimes referred to as a "persisted" computed column because the index stores the actual values of the computed column. For computed columns on complex or expensive expressions, using such an index could be faster than evaluating the expression anew. Note that, because the computed column must be evaluated to maintain the index, we cannot insert a "bad" row into T3. Any attempt to insert a "bad" row immediately fails with a conversion error.

I've deliberately included column A as part of the index so that the index covers all of the columns in the query. If we omit column A from the index, SQL Server cannot use the index without performing a bookmark lookup. In this particular example, that would prevent SQL Server from choosing the plan that I'm trying to demonstrate. Also, note that, on SQL Server 2005 we could use the INCLUDE keyword instead of making column A an index key, but I wanted this example to work on both SQL Server 2000 and SQL Server 2005.

Now let's compare the plans using the new table. First, the SQL Server 2000 plan:

|--Compute Scalar(DEFINE:([Expr1004]=Convert([T3].[B])))
       |--Hash Match(Inner Join, HASH:([T3].[A])=([T2].[X]), RESIDUAL:([T2].[X]=[T3].[A]))
            |--Table Scan(OBJECT:([T3]))
            |--Table Scan(OBJECT:([T2]))

Compare that to the SQL Server 2005 plan:

|--Hash Match(Inner Join, HASH:([T3].[A])=([T2].[X]), RESIDUAL:([T2].[X]=[T3].[A]))
       |--Compute Scalar(DEFINE:([T3].[C]=[T3].[C]))
       |    |--Index Scan(OBJECT:([T3].[T3C]))
       |--Table Scan(OBJECT:([T2]))

Notice that SQL Server 2000 uses the same plan as we saw above while SQL Server 2005 uses the new index and eliminates the conversion. This type of index matching is not limited to conversions and works for many other expressions and computed columns.

I researched the second benefit ("the prevention of redundant computation of expression results") but I'm unable to come up with a compelling explanation for it. In some cases, it is certainly true that pushing the conversion below a join reduces the number of times that the conversion is evaluated. For instance, returning to the original example above, suppose we add many duplicate values to T2 such that each T1 row joins multiple times. In the SQL Server 2005 plan, the conversion is evaluated before the join and so it is evaluated exactly once for each T1 row regardless of how many times each row joins. In the SQL Server 2000 plan, the conversion is evaluated after the join and so it is evaluated multiple times for each T1 row - once for each time that the row joins. Of course, it is also possible that none of the rows from T1 join. In this case, the SQL Server 2005 plan unnecessarily evaluates the conversion on every T1 row while the SQL Server 2000 plan does not evaluate the conversion at all.

Moreover, you may recall from my last post, that SQL Server defers the execution of most scalar expressions until they are actually evaluated. I used the following nested loops join example to illustrate this point:

SELECT T1.A, CONVERT(INT, T1.B) AS B_INT
FROM T1 JOIN T2 ON T1.A = T2.X
OPTION (LOOP JOIN)

|--Nested Loops(Inner Join, WHERE:([T2].[X]=[T1].[A]))
       |--Compute Scalar(DEFINE:([Expr1008]=CONVERT(int,[T1].[B],0)))
       |    |--Table Scan(OBJECT:([T1]))
       |--Table Scan(OBJECT:([T2]))

In this example, the compute scalar is below the join in the plan but the conversion is still executed after the join. Thus, pushing the conversion below the join does not change the number of times that it is executed.

Conversion and Arithmetic Errors

craigfr — Tue, 29 Apr 2008 02:23:00 GMT

Let's take a look at a simple query:

CREATE TABLE T1 (A INT, B CHAR(8))
INSERT T1 VALUES (0, '0')
INSERT T1 VALUES (1, '1')
INSERT T1 VALUES (99, 'Error')

SELECT T1.A, CONVERT(INT, T1.B) AS B_INT FROM T1

There is no way to convert the string "Error" into an integer, so it should come as no surprise that this query fails with a conversion error:

A           B_INT
----------- -----------
1           1
Msg 245, Level 16, State 1, Line 1
Conversion failed when converting the varchar value 'Error   ' to data type int.

Now, let's create a second table and try a join:

CREATE TABLE T2 (X INT)
INSERT T2 VALUES (1)
INSERT T2 VALUES (2)
INSERT T2 VALUES (3)
INSERT T2 VALUES (4)
INSERT T2 VALUES (5)

SELECT T1.A, CONVERT(INT, T1.B) AS B_INT
FROM T1 JOIN T2 ON T1.A = T2.X

Although this join query includes the same conversion as the first query, the row with T1.A = 99 does not join with any rows in T2, so at first glance, we might conclude that the conversion should never be executed. However, if we execute the query, we still get the error:

A           B_INT
----------- -----------
Msg 245, Level 16, State 1, Line 1
Conversion failed when converting the varchar value 'Error   ' to data type int.

What happened? The SQL Server query optimizer is free to move expressions up and down within a query plan. Since the expression with the conversion depends only on T1, the optimizer can (and does) push the conversion below the join and close to the scan of T1:

Now, let's see what happens if we force a nested loops join:

SELECT T1.A, CONVERT(INT, T1.B) AS B_INT
FROM T1 JOIN T2 ON T1.A = T2.X
OPTION (LOOP JOIN)

Once again, the optimizer pushes the conversion below the join, so we might conclude that this query will also fail. Surprisingly, it does not:

A           B_INT
----------- -----------
1           1

What's going on here? SQL Server includes a runtime optimization that defers the evaluation of most scalar expressions until they are actually referenced. We can see this optimization in action if we check the output of SET STATISTICS PROFILE ON:

1      1        |--Nested Loops(Inner Join, WHERE:([T2].[X]=[T1].[A]))
0      0             |--Compute Scalar(DEFINE:([Expr1008]=CONVERT(int,[T1].[B],0)))
3      1             |    |--Table Scan(OBJECT:([T1]))
15     3             |--Table Scan(OBJECT:([T2]))

Notice that the compute scalar is executed zero times. The result of the conversion is not needed by the join and is computed immediately prior to returning the query result to the client. By this time, the bad row has already been filtered by the join.

SQL Server actually uses the same optimization both for the nested loops join and for the hash join. However, recall that a hash join builds a hash table on its left input. This hash table includes values for all columns that are needed to evaluate the join and values for all columns that are output by the join. Thus, the hash join must evaluate and store the result of the conversion in the hash table. Thus, the conversion is evaluated and fails before the hash join can determine whether the bad row actually joins.

As you can see, whether or not a conversion causes a failure depends on a variety of factors including where in the plan the optimizer chooses to place the conversion and when during execution the conversion is actually evaluated. Moreover, when the conversion is actually evaluated depends on the precise operators in the plan and the behavior of those operators.

We can see similar problems with arithmetic errors such as overflows or divide by zero:

INSERT T1 VALUES (0, '0')

SELECT T1.A, 1 / T1.A AS A_Reciprocal
FROM T1 JOIN T2 ON T1.A = T2.X

A           A_Reciprocal
----------- ------------
Msg 8134, Level 16, State 1, Line 1
Divide by zero error encountered.

So, what can you do to work around this problem? The best solution from a performance perspective is to avoid using the conversion at all or to ensure that the data in the column to be converted is valid (or to avoid using an expression that could fail due to an arithmetic error). If you must use a conversion (or any other expression that could fail), you can use a CASE statement to validate the input. For example, the following query trims away leading and trailing spaces from the CHAR column and then uses the PATINDEX function to validate that the column does not contain any non-numeric characters:

SELECT T1.A,
    CASE WHEN PATINDEX('%[^0-9]%', RTRIM(LTRIM(T1.B))) = 0
        THEN CONVERT(INT, T1.B)
        ELSE NULL
    END AS B_INT
FROM T1

This example shows how we can avoid the divide by zero error:

SELECT T1.A,
    CASE WHEN T1.A <> 0
        THEN 1 / T1.A
        ELSE NULL
    END AS A_Reciprocal
FROM T1 JOIN T2 ON T1.A = T2.X

Although I would not recommend it, for arithmetic errors, you can use the SET ANSI_WARNINGS, SET ARITHABORT, and SET ARITHIGNORE options to disable the error. These settings do nothing for conversion errors.

Finally, it is worth pointing out that some hints can affect the placement of the conversion:

SELECT T1.A, CONVERT(INT, T1.B) AS B_INT
FROM T1 JOIN T2 ON T1.A = T2.X
OPTION (FORCE ORDER)

|--Compute Scalar(DEFINE:([Expr1008]=CONVERT(int,[T1].[B],0)))
       |--Hash Match(Inner Join, HASH:([T1].[A])=([T2].[X]), RESIDUAL:([T2].[X]=[T1].[A]))
            |--Table Scan(OBJECT:([T1]))
            |--Table Scan(OBJECT:([T2]))

Notice that the conversion is now computed after the join. I would strongly discourage the use of this hint as a workaround except perhaps in the simplest of queries given the number of side effects it has. Mostly I point out this particular result in case any readers are tempted to use this or other hints to explore how other join types and join orders might affect the behavior of this query.