SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

Actual Number of Rows are not always accurate

(Be sure to checkout the FREE SQLpassion Performance Tuning Training Plan - you get a weekly email packed with all the essential knowledge you need to know about performance tuning on SQL Server.)

Today’s blog posting is a quite interesting one, because I want to show you a concrete example where in an Actual Execution Plan the Actual Number of Rows are WRONG! Yes, you have read correctly: I’m talking here about the Actual Number of Rows, and not about the Estimated Number of Rows, which are always somehow wrong, because they are only estimated during the Cardinality Estimation.

Counting rows in the wrong way

A few weeks ago I had worked with a customer, and they had a really interesting phenomenon: SQL Server has returned a lot of rows, but when they looked into the Execution Plan, the Actual Number of Rows were a lot higher. You don’t trust me? Look at the following Actual Execution Plan within SQL Server Management Studio:

Counting rows in the wrong way...

SQL Server returned here within SQL Server Management Studio 110561 rows, but the Actual Number of Rows within the Actual Execution Plan are much higher: 118968!

Wow, this is a quite interesting behavior. And I don’t think that this behavior is just by-design. The problem lies in a Filtered Non-Clustered Columnstore Index that was introduced with SQL Server 2016. You can create a Filtered Non-Clustered Columnstore Index in an OLTP workload to support so-called Realtime Data Analytics Scenarios. Instead of creating a dedicated Data Warehouse database you perform your Analytics workload directly on your OLTP tables, which can be also changed concurrently.

This means now that a Non-Clustered Columnstore Index is also changeable since SQL Server 2016. And in that behavior lies the problem: when SQL Server calculates and returns you the Actual Number of Rows, the deleted rows from the Non-Clustered Columnstore Index are also considered. And therefore the Actual Number of Rows in the Execution Plan are just higher as the real row count that is returned from the query.

The following T-SQL code shows a simple scenario with which you can reproduce this scenario.

-- Create a table copy
SELECT * INTO Sales.SalesOrderDetail2 FROM Sales.SalesOrderDetail

-- Create a Non-Clustered ColumnStore Index for the "cold" data partition
WHERE ModifiedDate < '20140601'="" go="" --="" let's="" delete="" some="" rows="" delete="" from="" sales.salesorderdetail2="" where="" modifieddate="">= '20140501' AND ModifiedDate < '20140601'="" go="" --="" these="" rows="" are="" not="" logically="" deleted="" select="" *="" from="" sys.column_store_row_groups="" where="" object_id="OBJECT_ID('Sales.SalesOrderDetail2')" go="" --="" uses="" the="" non-clustered="" columnstore="" index="" to="" access="" the="" data="" select="" productid="" from="" sales.salesorderdetail2="" where="" modifieddate="">< '20140601'="" go="" --="" clean="" up="" drop="" table="" sales.salesorderdetail2="">


Never, ever trust anyone – especially not a piece of software! I find this behavior quite funny, because until I encountered this specific scenario I always thought that the Actual Number of Rows are somehow calculated on-the-fly during the Query Execution. But it seems (at least in combination with a Non-Clustered Columnstore Index) that this is not really always the case.

Thanks for your time,


Klaus Aschenbrenner

Klaus Aschenbrenner provides independent SQL Server Consulting Services across Europe and the US. Klaus works with the .NET Framework and especially with the SQL Server 2005/2008 from the very beginnings. In the years 2004 - 2005 Klaus was entitled with the MVP award from Microsoft for his tremendous support in the .NET Community. Klaus has also written the book Pro SQL Server 2008 Service Broker which was published by Apress in the Summer of 2008. Further information about Klaus you can find on his homepage at http://www.SQLpassion.at. He also twitters at http://twitter.com/Aschenbrenner.


Leave a comment on the original post [www.sqlpassion.at, opens in a new window]

Loading comments...