Bad execution plans when using parameters, subquery and partition by

Question

We have an issue with the following...
We have this table:
CREATE TABLE dbo.Test (
Dt date NOT NULL,
Nm int NOT NULL,
CONSTRAINT PK_Test PRIMARY KEY CLUSTERED (Dt)
This table can have data but it will not matter for this topic.
Consider this query (thanks Tom Phillips for simplifying my question):
declare @date as date = '2013-01-01'
select *
from (
select Dt,
row_number() over (partition by Dt order by Nm desc) a
from Test
where Dt = @date
) x
go
This query generates an execution plan with a clustered seek.
Our queries however needs the parameter outside of the sub-query:
declare @date as date = '2013-01-01'
select *
from (
select Dt,
row_number() over (partition by Dt order by Nm desc) a
from Test
) x
where Dt = @date
go
The query plan now does a scan followed by a filter on the date.
This is extremely inefficient.
This query plan is the same if you change the subquery into a CTE or a view (which is what we use).
We have this kind of setup all over the place and the only way to generate a good plan is if we use dynamic sql to select data from our views.
Is there any kind of solution for this?
We have tested this (with the same result) on SQL 2008R2, 2012 SP1, 2014 CU1.
Any help is appreciated.

Answer 1

Hi Tom,
Parameter sniffing is a different problem. A query plan is made based on the value which may be really off in the data distribution. We do have this problem as well e.g. when searching for today's data when the statistics think the table only has yesterday's
data (a problem we have a lot involves the lack of sufficient amount of buckets in statistics objects).
This problem is different.
- It doesn't matter what the parameter value is.
- You can reproduce this example with a fresh table. I.e. without statistics.
- No matter what the distribution of data (or even if the statistics are correct), there is absolutely no case possible (in my example) where doing a scan followed by a filter should have better results than doing a seek.
- You can't change the behavior with hints like "option(recompile)" or "optimize for".
This problem has to do with the specific combination of "partition by" and the filter being done outside of the immediate query. Try it out, play with the code, e.g. move the where clause inside the subquery. You'll see what I mean.
Thanks for responding.
Michel