Get rid of all the single quotes in your pivoted column references (both in the IN and in the top-level SELECT).

Cheers!

There's more than 1 version of the extended ASCII characters.

For reference like this (to compare to the output of CHAR), use the ISO 8859 table shown at http://www.ascii-code.com/

Also note that the plan is no longer a parallel plan.

If the original SELECT were making good use of those 10 threads, then running serially could well result...

Also, just to point out the elephant in the room, the slow plan is using the new cardinality estimator, while the fast one is using the old cardinality estimator. 

Since you're overwriting it anyway, just set it offline instead of setting it to single user.

Cheers!

Here's one way: 

SELECT p.name,
       sed.referenced_database_name,
       sed.referenced_schema_name,
       sed.referenced_entity_name
FROM   sys.procedures p
       INNER JOIN

Even without all the optimizer changes and effects from the new CE in play (once you're on compatibility level 100), there are a lot of ways a particular query might...

Exactly what metrics are you using? 

I'm guessing either active or usage (which is directly based on active).

A "low" value for those is NOT a good reason...

Steve's response reminds me of the other caveat for the query forms you used and I suggested, which is that they count multiple starts or ends for the same person...

Here's one way:

SELECT x.point,
   people_gained=SUM(CASE WHEN x.point_type='End'   THEN 1  ELSE 0 END),
   people_left =SUM(CASE WHEN x.point_type='Start' THEN -1 ELSE 0 END),
  ...