Jaime,

Yes, it’s quite possible, as the estimate for TVF optimization changed in 2012 (I believe). These links provide more details:

http://blogs.msdn.com/b/psssql/archive/2014/04/01/sql-server-2014-s-new-cardinality-estimator-part-1.aspx

http://blogs.msdn.com/b/psssql/archive/2010/10/28/query-performance-and-multi-statement-table-valued-functions.aspx

HTH

I am using SQL Server 2014 and experiencing a weird behavior related to Compatibility Levels and (I think) Cardinality Estimator.

The problem is that a query gets a much worse execution plan with Compatibility Level set to 110 or 120 than with CL set to 100 (SQL 2008).

I could expect some queries performing worse with CL 120 due to the new Cardinality Estimator, but I am somehow confused because the execution plan changes when I switch from 100 to 110, but it is the same for 110 and 120.

The query involves a scalar UDF in the WHERE clause (I am currently trying to refactor the query and avoid that). The estimates for that query with CL 100 were correct, since only a row was affected each time and, thus, the UDF was executed only once. But with CL 110 and 120 the execution plan shows hight values for estimated rows and this makes the UDF to be evaluated many times, and it is hurting performance.

I have guessed that this might be related to the problem with Ascending Keys, and I was lucky before, with CL 100, because it made SQL Server estimate just one (or zero) row, while now it estimates that new rows exist over the max value in the histogram.

But had this changed already for SQL Server 2012 or for SQL Server 2014 with CL = 110?

Thanks a lot and Kind Regards,

Jaime

Kevin,

Thanks for reading, and THANK YOU for the detailed comments! I’m going to reply to each of your points, not because I am looking to debate but because I want to offer additional thoughts that I feel may add more value to the above post.

1) Glad you agree! While the extra RAM available for Standard edition is a wonderful thing, none of that matters if the CE is building you a sub-optimal plan. That’s why in my first post I talked about how the CE is a lot like our DNA: we can’t see it, but it’s there, and it makes you you, and it’s not a trivial piece of code.

2) Fair point, and that was my thinking behind the comment “I’d prefer to use the new CE until my data forces me to revert to the legacy CE for some query”.

3) Yes, this is a mess right now! If users have been using the 2389 and 2390 traceflags then they should be aware of the issues between versions and know what updates they need. I didn’t want to dive into this in this post, as I think the topic deserves it’s own post entirely.

Your link wasn’t working, so I am putting it here again: http://support.microsoft.com/kb/2952101

Thanks again Kevin!

2) I think there will be a fair bit of pain from the over-estimation issue as more queries switch from nested loop/index seek plans to scans/hashes “earlier” than they would have otherwise given the same statistics on the old CE. Those plans can be SIGNIFICANTLY slower from many perspectives including memory grant (with potentially deadly tempdb spills), physical IO and even CPU. The massive amounts of LOGICAL IOs that come from a high-row-count loop/seek plan are just that – logical – and are typically very fast to iterate, result in fewer physical IOs, require far smaller memory grants and are less prone to locking/blocking issues (as long as they stay at the row/page level with their locks).

3) Beware the ascending key issue. There is a bug in SQL 2014 that was supposedly fixed in CU2 (http://support.microsoft.com/kb/2952101). I say supposedly because Dave Ballantyne posted in the Data Platform Advisors Yammer group questioning the patches’ effectiveness. (https://www.yammer.com/bpdtechadvisors/#/Threads/show?threadId=414052667).

Best,

Kevin