Question

Is anyone here able to provide information on what optimisations SQL Server is capable of? I’m using 2005 standard edition, but also work with 2008 on occasion. Is 2008 able to perform query optimisations that 2005 can’t?

Sometimes I’ll run a query and it will take an enormous amount of time for no apparent reason, and I have to rewrite it using a different method. (CTEs instead of subqueries, etc) I’m like to know ahead of time whether SQL server is going to give me optimal or near-optional performance from a query before I start using it.

Joins to subqueries

select ... from tbl1 left join(
    select ... from tbl2 group by ...
) as subQ on t1.pk = subQ.fk
where t1.pk between 50 and 100

If I join a table to a subquery as above, and the result set is filtered, can I expect SQL server to propagate the WHERE clause filters down to all relevent subqueries? How good is the compiler at determining which parts of a result set will end up being used in the final output?

Lots of columns in group by

Subqueries with group bys can often by written as a straight up join, but then it’s necessary to reference many columns in the group by

select tbl1.pk,b,c,d,e,f,g, sum(tbl2.h) from tbl1 
inner join tbl2 on tbl1.pk = tbl2.fk
inner join tbl3 on tbl1.fk = tbl3.pk
group by tbl1.pk, tbl1.b, tbl3.c, tbl3.d, tbl3.e, tbl3.f, tbl3.g

Each row in table 1 will match to multiple rows in table 2, in addition to one row in table 3. (Note the join to table 3’s pk) Due to this, all the columns in the group by except for tbl1.pk are superfluous. But SQL requires that they are used in the group by regardless. Now the optimiser should just be sorting on table 1’s primary key in order to aggregate the rows from table 2. Will it do this, or will it needlessly sort and compare the entire column set in the group by? As mentioned, the alternative is to aggregate table 2 in a subquery and then join back to tables 1 and 3. Does this make any difference?

Answer 1

Yes 2008 is capable of additional optimisations.

One indicator of this is that sys.dm_exec_query_transformation_stats has 390 potential transformations on my 2008 instance and 380 on my 2005 instance (Some explanation on this DMV here).

In general the differences are evolutionary improvements however rather than dramatic. I’ve found from my own experience of reporting minor performance issues on Connect that they tend to be fixed next version rather than backported to previous versions (e.g. 1, e.g. 2)

A few areas I am aware of that have improved in 2008 are handling of partitioned tables, query plans for dynamic search conditions when the OPTION (RECOMPILE) plan is used and predicate pushing in Views.

With regard to the specific scenarios you’ve raised you would need to check the execution plans in both versions to see if you can discern any difference in strategy.