Question

I never questioned any efficiency difference between the following two scripts:

DateKey is type INT

1.

DECLARE @StartDate  INT = 20130101,
        @EndDate    INT = 20130201

SELECT  UserAccountKey,
        income_LT = SUM(ISNULL(income,0.0)) 
INTO    #x
FROM    WH.dbo.xxx x
WHERE   x.DateKey > = @StartDate
        AND x.DateKey < @EndDate
GROUP BY    UserAccountKey

Execution for the above is:

2.

SELECT  UserAccountKey,
        income_LT = SUM(ISNULL(income,0.0)) 
INTO    #x
FROM    WH.dbo.xxx x
WHERE   x.DateKey > = 20130101
        AND x.DateKey < 20130201
GROUP BY    UserAccountKey

Here is the execution plan for number 2:

1. is a lot faster (2 seconds compared to 80 seconds) – is this as expected? Why?

Answer 1

On the first query it uses variables. The value of these is not known at compilation time so it produces a plan based on generic estimates. On the second one it compiles a plan based on the actual parameter values.

The fact that the generic guesses work out better than the plan where it knows the specific values indicates that probably your statistics need updating.

Likely last time they were updated few if any rows matched the WHERE DateKey > = 20130101 AND DateKey < 20130201 predicate but now many do.

This is a common issue with ascending date columns

See also this question and answers on the dba site

Edit This can be seen in the plan here

The thickness of the lines indicate the number of rows. The very thin line to the left of the compute scalar shows the estimated number of rows (actual row counts often aren’t shown for compute scalars for the reasons here). The very thick lines into the compute scalar and out of the sort represent the actual number of rows. The two are clearly very different.

As well as choosing an inappropriate plan (serial with nested loops join) this poor estimate also means that the sort spilled to disc as the query requested an insufficient memory grant (shown by the warning triangle).