Craig Freedman's SQL Server Blog : Common Table Expressions

Recursive CTEs continued ...

craigfr — Thu, 08 Nov 2007 00:58:00 GMT

In this post, I will finish the discussion of recursive CTEs that I began in my last post. I will continue to use the CTE examples from Books Online. To run these examples, you'll need to install the Adventure Works Cycles OLTP sample database.

In my last post, I explained that all recursive queries follow the same pattern of one or more anchor sub-selects and one or more recursive sub-selects combined by a UNION ALL. Similarly, all recursive query plans also follow the same pattern which looks like so:

|--Index Spool(WITH STACK)
       |--Concatenation
            |--Compute Scalar(DEFINE:([Expr10XX]=(0)))
            |    |--... anchor sub-select plan(s) ...
            |--Assert(WHERE:(CASE WHEN [Expr10ZZ]>(100) THEN (0) ELSE NULL END))
                 |--Nested Loops(Inner Join, OUTER REFERENCES:([Expr10YY], [Recr10XX], ...))
                      |--Compute Scalar(DEFINE:([Expr10ZZ]=[Expr10YY]+(1)))
                      |    |--Table Spool(WITH STACK)
                      |--... recursive sub-select plan(s) ...

Because of this basic plan shape, SQL Server cannot execute recursive queries using parallel plans. There are two basic problems. First, the stack spool does not support parallel execution. Second, the nested loops join does not support parallel execution on its inner input.

Finally, let's look at how the placement of a WHERE clause can have a big impact on the performance of a recursive query. In my last post, I dissected a recursive query that returns a list of all employees and their level within the organization. Suppose that we want to run the same query but limit the results to those employees in the first two levels. We could write the following query (which you'll also find in Books Online) with an extra WHERE clause to limit the results:

WITH DirectReports(ManagerID, EmployeeID, EmployeeLevel) AS
(
    SELECT ManagerID, EmployeeID, 0 AS EmployeeLevel
    FROM HumanResources.Employee
    WHERE ManagerID IS NULL
    UNION ALL
    SELECT e.ManagerID, e.EmployeeID, EmployeeLevel + 1
    FROM HumanResources.Employee e
        INNER JOIN DirectReports d
        ON e.ManagerID = d.EmployeeID
)
SELECT ManagerID, EmployeeID, EmployeeLevel
FROM DirectReports
WHERE EmployeeLevel <= 2

This query computes uses essentially the same plan as the query without the extra WHERE clause. The WHERE clause simply introduces a filter operator at the root of the plan:

Rows   Executes
34     1        |--Filter(WHERE:([Recr1012]<=(2)))
290    1             |--Index Spool(WITH STACK)
290    1                  |--Concatenation
0      0                       |--Compute Scalar(DEFINE:([Expr1013]=(0)))
0      0                       |    |--Compute Scalar(DEFINE:([Expr1003]=(0)))
1      1                       |         |--Index Seek(OBJECT:([Employee].[IX_Employee_ManagerID]), SEEK:([ManagerID]=NULL) ...)
289    1                       |--Assert(WHERE:(CASE WHEN [Expr1015]>(100) THEN (0) ELSE NULL END))
289    1                            |--Nested Loops(Inner Join, OUTER REFERENCES:([Expr1015], [Recr1006], [Recr1007], [Recr1008]))
0      0                                 |--Compute Scalar(DEFINE:([Expr1015]=[Expr1014]+(1)))
290    1                                 |    |--Table Spool(WITH STACK)
0      0                                 |--Compute Scalar(DEFINE:([Expr1009]=[Recr1008]+(1)))
289    290                                    |--Index Seek(OBJECT:([Employee].[IX_Employee_ManagerID]), SEEK:([ManagerID]=[Recr1007]) ...)

As you can see from the row counts, this query computes the level of every employee in the organization before discarding the results that we do not want. Now, suppose that we instead move the WHERE clause into the recursive sub-select:

WITH DirectReports(ManagerID, EmployeeID, EmployeeLevel) AS
(
    SELECT ManagerID, EmployeeID, 0 AS EmployeeLevel
    FROM HumanResources.Employee
    WHERE ManagerID IS NULL
    UNION ALL
    SELECT e.ManagerID, e.EmployeeID, EmployeeLevel + 1
    FROM HumanResources.Employee e
        INNER JOIN DirectReports d
        ON e.ManagerID = d.EmployeeID
    WHERE EmployeeLevel < 2
)
SELECT ManagerID, EmployeeID, EmployeeLevel
FROM DirectReports

This query is semantically identical to the previous query, but if we look at the plan, we can see that the filter moves into the recursive portion of the plan:

Rows   Executes
34     1        |--Index Spool(WITH STACK)
34     1             |--Concatenation
0      0                  |--Compute Scalar(DEFINE:([Expr1013]=(0)))
0      0                  |    |--Compute Scalar(DEFINE:([Expr1003]=(0)))
1      1                  |         |--Index Seek(OBJECT:([Employee].[IX_Employee_ManagerID]), SEEK:([ManagerID]=NULL) ...)
33     1                  |--Assert(WHERE:(CASE WHEN [Expr1015]>(100) THEN (0) ELSE NULL END))
33     1                       |--Nested Loops(Inner Join, OUTER REFERENCES:([Expr1015], [Recr1006], [Recr1007], [Recr1008]))
0      0                            |--Compute Scalar(DEFINE:([Expr1015]=[Expr1014]+(1)))
34     1                            |    |--Table Spool(WITH STACK)
0      0                            |--Compute Scalar(DEFINE:([Expr1009]=[Recr1008]+(1)))
33     34                                |--Nested Loops(Inner Join)
7      34                                     |--Filter(WHERE:(STARTUP EXPR([Recr1008]<(2))))
7      7                                      |    |--Constant Scan
33     7                                      |--Index Seek(OBJECT:([Employee].[IX_Employee_ManagerID]), SEEK:([ManagerID]=[Recr1007]) ...)

Notice from the row counts that the new plan computes only the portion of the result set that really interests us and then terminates the recursion.

You may also observe than the plan now has a startup filter. An ordinary filter reads rows from its input tree and then evaluates a Boolean expression on each row to determine whether to return it. A startup filter evaluates its expression only once per execution. The expression does not depend on the input rows. If the expression evaluates to true, the startup filter returns all of its input rows. If the expression evaluates to false, the startup filter returns no rows.

In this example, if the startup filter expression evaluates to true, the constant scan returns one row to the nested loops join immediately above the filter and this join then executes the index seek on its inner input. However, if the startup filter expression evaluates to false, the filter and then the nested loops join return no rows.

While there are many scenarios where a startup filter is genuinely useful, this plan is slightly more complex than is really necessary. The plan could have used an ordinary filter:

|--Index Spool(WITH STACK)
       |--Concatenation
            |--Compute Scalar(DEFINE:([Expr1013]=(0)))
            |    |--Compute Scalar(DEFINE:([Expr1003]=(0)))
            |         |--Index Seek(OBJECT:([HumanResources].[Employee].[IX_Employee_ManagerID]), SEEK:([HumanResources].[Employee].[ManagerID]=NULL) ORDERED FORWARD)
            |--Assert(WHERE:(CASE WHEN [Expr1015]>(100) THEN (0) ELSE NULL END))
                 |--Nested Loops(Inner Join, OUTER REFERENCES:([Expr1015], [Recr1006], [Recr1007], [Recr1008]))
                      |--Filter(WHERE:([Recr1008]<(2)))
                      |    |--Compute Scalar(DEFINE:([Expr1015]=[Expr1014]+(1)))
                      |         |--Table Spool(WITH STACK)
                      |--Compute Scalar(DEFINE:([Expr1009]=[Recr1008]+(1)))
                           |--Index Seek(OBJECT:([HumanResources].[Employee].[IX_Employee_ManagerID] AS [e]), SEEK:([e].[ManagerID]=[Recr1007]) ORDERED FORWARD)

Note that this plan is artificial. You cannot get SQL Server to generate it.

Recursive CTEs

craigfr — Thu, 25 Oct 2007 21:57:00 GMT

One of the most important uses of CTEs is to write recursive queries. In fact, CTEs provide the only means to write recursive queries. As I noted last week, there are several excellent CTE examples, including recursive CTE examples, in Books Online. I'll once again start with the examples from Books Online. To run these examples, you'll need to install the Adventure Works Cycles OLTP sample database.

Recursive CTEs always follow the same pattern. The body of the CTE is a UNION ALL query that combines one or more anchor sub-selects which seed the result set and one or more recursive sub-selects which generate the remainder of the result set. The recursive sub-selects reference the recursive CTE itself.

Let's look at a simple example which computes a list of all employees and their level within the organization. Computing the level with the organization can only be done using a recursive CTE as it requires counting the number of joins required to reach each employee:

WITH DirectReports(ManagerID, EmployeeID, EmployeeLevel) AS
(
    SELECT ManagerID, EmployeeID, 0 AS EmployeeLevel
    FROM HumanResources.Employee
    WHERE ManagerID IS NULL
    UNION ALL
    SELECT e.ManagerID, e.EmployeeID, EmployeeLevel + 1
    FROM HumanResources.Employee e
        INNER JOIN DirectReports d
        ON e.ManagerID = d.EmployeeID
)
SELECT ManagerID, EmployeeID, EmployeeLevel
FROM DirectReports

This example has a single anchor sub-select and a single recursive sub-select. The anchor sub-select computes a list of top level employees who have no manager (in this case, there is only one such employee) and assigns these employees level 0. The recursive sub-select then searches for employees, who work for each top level manager, and assigns these employees level 1. The process then repeats with the recursive sub-select searching for employees progressively deeper within the organization. The query terminates when it reaches employees who are not managers. At this point the recursive sub-select returns no further employees.

Now let's look at the plan used by this query:

|--Index Spool(WITH STACK)
       |--Concatenation
            |--Compute Scalar(DEFINE:([Expr1013]=(0)))
            |    |--Compute Scalar(DEFINE:([Expr1003]=(0)))
            |         |--Index Seek(OBJECT:([HumanResources].[Employee].[IX_Employee_ManagerID]), SEEK:([HumanResources].[Employee].[ManagerID]=NULL) ORDERED FORWARD)
            |--Assert(WHERE:(CASE WHEN [Expr1015]>(100) THEN (0) ELSE NULL END))
                 |--Nested Loops(Inner Join, OUTER REFERENCES:([Expr1015], [Recr1006], [Recr1007], [Recr1008]))
                      |--Compute Scalar(DEFINE:([Expr1015]=[Expr1014]+(1)))
                      |    |--Table Spool(WITH STACK)
                      |--Compute Scalar(DEFINE:([Expr1009]=[Recr1008]+(1)))
                           |--Index Seek(OBJECT:([HumanResources].[Employee].[IX_Employee_ManagerID] AS [e]), SEEK:([e].[ManagerID]=[Recr1007]) ORDERED FORWARD)

Like the query itself, this plan has two parts: an anchor part and a recursive part. These two parts are "glued" together using the concatenation operator which implements the UNION ALL.

The single most interesting operator in this plan is the spool. This is a special spool known as a stack spool. A stack spool is a bit like a common subexpression spool in that it has a primary instance which loads input rows into the worktable and a secondary instance which reads and returns the rows from the worktable. The primary spool has a child since it load input rows while the secondary spool does not have a child since it merely reads and returns the rows loaded by the primary spool. (See my posts on Optimized Non-clustered Index Maintenance in Per-Index Plans and Aggregation WITH CUBE for examples of common subexpression spools.)

Unlike ordinary common subexpression spools which eagerly load all rows into the worktable before returning any rows, a stack spool is a lazy spool which means that it begins returning rows immediately. The primary spool (the topmost operator in the plan) is fairly mundane. Like any other lazy spool, it reads each input row, inserts the row into the spool, and returns the row to the client. The secondary spool (below the nested loops join) is where all the interesting action is. Each time the nested loops join requests a row from the secondary spool, the spool reads the last row from the spool, returns it, and then deletes it to ensure that it is not returned more than once. Note that the term stack spool comes from this last in first out behavior. The primary spool pushes rows onto the stack and the secondary spool pops rows off of the stack.

Now that we understand how the spool works, let's step through the plan and see how it works. The query processor begins by executing the first input to the concatenation operator which also happens to be the anchor part of the plan. This part of the plan uses an index seek to find all employees who have no manager. The index seek returns the following row which the primary spool inserts into the worktable:

ManagerID   EmployeeID  EmployeeLevel
----------- ----------- -------------
NULL        109         0

Once it finishes executing the anchor part of the plan, the query processor continues by executing the second input to the concatenation operator which happens to be the recursive part of the plan. This part of the plan has a nested loops join with the secondary spool as its outer input. The nested loops join requests a row from the spool which so far contains only the one row for employee 109. The spool returns this row and deletes it from the worktable. The join then executes the index seek on its inner input to find all employees who work for employee 109. This index seek returns the following rows which the primary spool inserts into the worktable:

ManagerID   EmployeeID  EmployeeLevel
----------- ----------- -------------
109         6           1
109         12          1
109         42          1
109         140         1
109         148         1
109         273         1

Next, the nested loops join requests another row from the secondary spool. This time the worktable contains the six rows shown above, so the spool returns (and deletes) the last row corresponding to employee 273. The nested loops join again executes the index seek on its inner input and returns the following rows:

ManagerID   EmployeeID  EmployeeLevel
----------- ----------- -------------
273         268         2
273         284         2
273         288         2

Now the worktable contains the following rows:

ManagerID   EmployeeID  EmployeeLevel
----------- ----------- -------------
109         6           1
109         12          1
109         42          1
109         140         1
109         148         1
273         268         2
273         284         2
273         288         2

This process repeats continuing with employee 288. Eventually, the spool returns a row corresponding to an employee who is not a manager. At that point, the index seek on the inner side of the join returns no rows. After the join consumes the final row from the spool, the query terminates.

There are few other interesting points worth noting about this plan. First, the plan includes two sets of compute scalars to compute the recursion level. One set ([Expr1003] and [Expr1009]) is used to compute EmployeeLevel. The other set ([Expr1013] and [Expr1015]) is generated internally and used by the assert operator to ensure that the query terminates and does not get into an infinite loop. If you repeat this query without EmployeeLevel, you will see that one set of the compute scalars disappears from the plan while the internally generated set remains.

We can control the maximum recursion level. For example, if you run the query with OPTION (MAXRECURSION 2), you will see that the constant in the assert operator changes from the default of 100 to 2. Since this query requires more than two levels of recursion to complete, if you execute it with this option, it will fail with the following error:

Msg 530, Level 16, State 1, Line 1
The statement terminated. The maximum recursion 2 has been exhausted before statement completion.

In my next post I'll continue this discussion of recursive CTEs.

CTEs (Common Table Expressions)

craigfr — Thu, 18 Oct 2007 22:59:00 GMT

CTEs or common table expressions, which are new in SQL Server 2005, provide an easy way to break a complex SQL statement down into smaller more manageable queries. CTEs are is some ways very much like views. Unlike a view which can be created once and used by many SQL statements, a CTE is associated with a single SQL statement. There are several excellent CTE examples, including recursive CTE examples, in Books Online. Rather than construct entirely new examples for this post, I've started with the examples from Books Online. To run these examples, you'll need to install the Adventure Works Cycles OLTP sample database.

Let's start with the following simple example:

WITH DirReps(ManagerID, DirectReports) AS
(
    SELECT ManagerID, COUNT(*)
    FROM HumanResources.Employee AS e
    WHERE ManagerID IS NOT NULL
    GROUP BY ManagerID
)
SELECT ManagerID, DirectReports
FROM DirReps
ORDER BY ManagerID

This query is identical to the following simpler query:

SELECT ManagerID, COUNT(*) AS DirectReports
FROM HumanResources.Employee AS e
WHERE ManagerID IS NOT NULL
GROUP BY ManagerID
ORDER BY ManagerID

SQL Server expands the CTE without materializing it. Thus, both queries produce the same query plan:

|--Compute Scalar(DEFINE:([Expr1002]=CONVERT_IMPLICIT(int,[Expr1005],0)))
|--Stream Aggregate(GROUP BY:([e].[ManagerID]) DEFINE:([Expr1005]=Count(*)))
|--Index Seek(OBJECT:([HumanResources].[Employee].[IX_Employee_ManagerID] AS [e]), SEEK:([e].[ManagerID] IsNotNull) ORDERED FORWARD)

CTEs are more useful when a query includes multiple instances of the same sub-select. For example, the following query computes the number of orders sold by and the most recent order date for each Adventure Works employee and then computes the same information for each employee's manager. Rather than repeat the sub-select that computes the number of orders and the most recent order date, we can use a CTE to make the query simpler and clearer:

WITH Sales_CTE (SalesPersonID, NumberOfOrders, MaxDate)
AS
(
    SELECT SalesPersonID, COUNT(*), MAX(OrderDate)
    FROM Sales.SalesOrderHeader
    GROUP BY SalesPersonID
)
SELECT E.EmployeeID, OS.NumberOfOrders, OS.MaxDate,
    E.ManagerID, OM.NumberOfOrders, OM.MaxDate
FROM HumanResources.Employee AS E
    JOIN Sales_CTE AS OS
    ON E.EmployeeID = OS.SalesPersonID
    LEFT OUTER JOIN Sales_CTE AS OM
    ON E.ManagerID = OM.SalesPersonID
ORDER BY E.EmployeeID

We could write this query without the CTE as:

SELECT E.EmployeeID, OS.NumberOfOrders, OS.MaxDate,
    E.ManagerID, OM.NumberOfOrders, OM.MaxDate
FROM HumanResources.Employee AS E
    JOIN (
        SELECT SalesPersonID, COUNT(*) AS NumberOfOrders, MAX(OrderDate) AS MaxDate
        FROM Sales.SalesOrderHeader
        GROUP BY SalesPersonID
        ) AS OS
    ON E.EmployeeID = OS.SalesPersonID
    LEFT OUTER JOIN (
        SELECT SalesPersonID, COUNT(*) AS NumberOfOrders, MAX(OrderDate) AS MaxDate
        FROM Sales.SalesOrderHeader
        GROUP BY SalesPersonID
        ) AS OM
    ON E.ManagerID = OM.SalesPersonID
ORDER BY E.EmployeeID

Alternatively, we could use a view although that requires explicitly creating a view (and dropping it if you do not want to persist it). Views are less convenient and more costly (the DDL is not free) than CTEs. If you do create and drop views on the fly, you must also be careful not to use a name that will not conflict with other sessions that might also create the same view.

CREATE VIEW Sales_View (SalesPersonID, NumberOfOrders, MaxDate) AS
SELECT SalesPersonID, COUNT(*), MAX(OrderDate)
FROM Sales.SalesOrderHeader
GROUP BY SalesPersonID
GO
SELECT E.EmployeeID, OS.NumberOfOrders, OS.MaxDate,
    E.ManagerID, OM.NumberOfOrders, OM.MaxDate
FROM HumanResources.Employee AS E
    JOIN Sales_View AS OS
    ON E.EmployeeID = OS.SalesPersonID
    LEFT OUTER JOIN Sales_View AS OM
    ON E.ManagerID = OM.SalesPersonID
ORDER BY E.EmployeeID;
GO
DROP VIEW Sales_View
GO

All three of these variations produce the same query plan:

|--Nested Loops(Left Outer Join, WHERE:([E].[ManagerID]=[Sales].[SalesOrderHeader].[SalesPersonID]))
       |--Sort(ORDER BY:([E].[EmployeeID] ASC))
       |    |--Nested Loops(Inner Join, OUTER REFERENCES:([Sales].[SalesOrderHeader].[SalesPersonID]))
       |         |--Compute Scalar(DEFINE:([Expr1005]=CONVERT_IMPLICIT(int,[Expr1021],0)))
       |         |    |--Hash Match(Aggregate, HASH:([Sales].[SalesOrderHeader].[SalesPersonID]), RESIDUAL:(...) DEFINE:([Expr1021]=COUNT(*), [Expr1006]=MAX([Sales].[SalesOrderHeader].[OrderDate])))
       |         |         |--Clustered Index Scan(OBJECT:([Sales].[SalesOrderHeader].[PK_SalesOrderHeader_SalesOrderID]))
       |         |--Clustered Index Seek(OBJECT:([HumanResources].[Employee].[PK_Employee_EmployeeID] AS [E]), SEEK:([E].[EmployeeID]=[Sales].[SalesOrderHeader].[SalesPersonID]) ORDERED FORWARD)
       |--Table Spool
            |--Compute Scalar(DEFINE:([Expr1010]=[Expr1010], [Expr1011]=[Expr1011]))
                 |--Compute Scalar(DEFINE:([Expr1010]=CONVERT_IMPLICIT(int,[Expr1022],0)))
                      |--Hash Match(Aggregate, HASH:([Sales].[SalesOrderHeader].[SalesPersonID]), RESIDUAL:(...) DEFINE:([Expr1022]=COUNT(*), [Expr1011]=MAX([Sales].[SalesOrderHeader].[OrderDate])))
                           |--Clustered Index Scan(OBJECT:([Sales].[SalesOrderHeader].[PK_SalesOrderHeader_SalesOrderID]))

Notice that this query plan computes the CTE result twice (once for each reference). We have two scans of the SalesOrderHeader table and two hash aggregates. Even with the CTE (or the view), SQL Server still computes the result twice. Do not be fooled by the table spool. This spool merely caches the CTE result to avoid computing the entire aggregate once per employee.

We could force SQL Server to compute the CTE result only once by explicitly materializing it using a table variable, a temp table, or an indexed view. Here is an example using a table variable:

DECLARE @Sales_Data TABLE (SalesPersonID INT, NumberOfOrders INT, MaxDate DATETIME)

INSERT @Sales_Data
SELECT SalesPersonID, COUNT(*), MAX(OrderDate)
FROM Sales.SalesOrderHeader
GROUP BY SalesPersonID

SELECT E.EmployeeID, OS.NumberOfOrders, OS.MaxDate,
    E.ManagerID, OM.NumberOfOrders, OM.MaxDate
FROM HumanResources.Employee AS E
    JOIN @Sales_Data AS OS
    ON E.EmployeeID = OS.SalesPersonID
    LEFT OUTER JOIN @Sales_Data AS OM
    ON E.ManagerID = OM.SalesPersonID
ORDER BY E.EmployeeID

This rewrite has two statements and, thus, has two plans. The first plan materializes the CTE result into a table variable while the second plan reads this result twice.

|--Table Insert(OBJECT:(@Sales_Data), SET:([SalesPersonID] = [Sales].[SalesOrderHeader].[SalesPersonID],[NumberOfOrders] = [Expr1007],[MaxDate] = [Expr1008]))
       |--Top(ROWCOUNT est 0)
            |--Compute Scalar(DEFINE:([Expr1007]=CONVERT_IMPLICIT(int,[Expr1012],0)))
                 |--Hash Match(Aggregate, HASH:([Sales].[SalesOrderHeader].[SalesPersonID]), RESIDUAL:(...) DEFINE:([Expr1012]=COUNT(*), [Expr1008]=MAX([Sales].[SalesOrderHeader].[OrderDate])))
                      |--Clustered Index Scan(OBJECT:([Sales].[SalesOrderHeader].[PK_SalesOrderHeader_SalesOrderID]))

|--Nested Loops(Left Outer Join, WHERE:([E].[ManagerID]=[OM].[SalesPersonID]))
       |--Nested Loops(Inner Join, OUTER REFERENCES:([OS].[SalesPersonID]))
       |    |--Sort(ORDER BY:([OS].[SalesPersonID] ASC))
       |    |    |--Table Scan(OBJECT:(@Sales_Data AS [OS]))
       |    |--Clustered Index Seek(OBJECT:([HumanResources].[Employee].[PK_Employee_EmployeeID] AS [E]), SEEK:([E].[EmployeeID]=[OS].[SalesPersonID]) ORDERED FORWARD)
       |--Table Scan(OBJECT:(@Sales_Data AS [OM]))

Explicitly materializing a CTE (or view or sub-select) result does not always yield better performance. First, we must consider the cost of creating and writing the temp table. If the cost of computing the CTE is not too great, it may be cheaper simply to compute the CTE result multiple times. Second, in some cases, the query optimizer may be able to choose a better plan and avoid computing the entire CTE result. For example, suppose that we only want to compute the number of orders for a single employee:

DECLARE @EID INT
SET @EID = 268;

WITH Sales_CTE (SalesPersonID, NumberOfOrders, MaxDate)
AS
(
    SELECT SalesPersonID, COUNT(*), MAX(OrderDate)
    FROM Sales.SalesOrderHeader
    GROUP BY SalesPersonID
)
SELECT E.EmployeeID, OS.NumberOfOrders, OS.MaxDate,
    E.ManagerID, OM.NumberOfOrders, OM.MaxDate
FROM HumanResources.Employee AS E
    JOIN Sales_CTE AS OS
    ON E.EmployeeID = OS.SalesPersonID
    LEFT OUTER JOIN Sales_CTE AS OM
    ON E.ManagerID = OM.SalesPersonID
WHERE E.EmployeeID = @EID

This query yields a different plan from the original query:

|--Nested Loops(Left Outer Join, OUTER REFERENCES:([E].[ManagerID]))
       |--Nested Loops(Inner Join)
       |    |--Clustered Index Seek(OBJECT:([HumanResources].[Employee].[PK_Employee_EmployeeID] AS [E]), SEEK:([E].[EmployeeID]=[@EID]) ORDERED FORWARD)
       |    |--Compute Scalar(DEFINE:([Expr1005]=CONVERT_IMPLICIT(int,[Expr1021],0)))
       |         |--Stream Aggregate(DEFINE:([Expr1021]=Count(*), [Expr1006]=MAX([Sales].[SalesOrderHeader].[OrderDate])))
       |              |--Clustered Index Scan(OBJECT:([Sales].[SalesOrderHeader].[PK_SalesOrderHeader_SalesOrderID]), WHERE:([Sales].[SalesOrderHeader].[SalesPersonID]=[@EID]))
       |--Compute Scalar(DEFINE:([Expr1010]=[Expr1010], [Expr1011]=[Expr1011]))
            |--Compute Scalar(DEFINE:([Expr1010]=CONVERT_IMPLICIT(int,[Expr1022],0)))
                 |--Stream Aggregate(DEFINE:([Expr1022]=Count(*), [Expr1011]=MAX([Sales].[SalesOrderHeader].[OrderDate])))
                      |--Clustered Index Scan(OBJECT:([Sales].[SalesOrderHeader].[PK_SalesOrderHeader_SalesOrderID]), WHERE:([E].[ManagerID]=[Sales].[SalesOrderHeader].[SalesPersonID]))

While the original plan computed the number of orders and the most recent order date for all employees, this plan only computes this information for a single employee and for that employee's manager. Observe the WHERE predicates on the clustered index scans of the SalesOrderHeader table. Moreover, notice that this plan uses scalar stream aggregates instead of the hash aggregates in the original plan. Finally, in this example, the optimizer chose scans, but if the tables involved were larger and the predicates were more selective, it would have chosen index seeks to avoid scanning the entire table.

In my next post I'll take a look at what is perhaps the most important use of CTEs: recursive CTEs.