Misleading data in execution plans when a row goal is used
SELECT TOP (2000) SalesOrderID,
WHERE OrderQty < 3;
In the exexcution plan for this sample query in AdventureWorks, check the properties of the Clustered Index Scan operator.
For the cardinality estimates we can look at Estimated Number of Rows (shown in SSMS as Estimated Number of Rows to be Read) and at EstimateRowsWithoutRowGoal to get a good idea of work to be done and how much it would have been without the row goal. So far so good.
But another property Estimated Number of Rows to be Read, in very confusing. It actually displays the estimated number of rows to be read without applying the row goal. To prevent confusion, either the property should be renamed to Estimated Number of Rows to be Read Without RowGoal; or the value shown in this property should be scaled down to the row goal.
Similart, the Estimated CPU Cost and Estimated I/O Cost properties of the operator are based on "without row goal", but the "Estimated Operator Cost" and "Estimated Subtree Cost" properties are based on "with row goal". Again, a very confusing and misleading inconsistency that can be fixed by either adding "without row goal" to properties that are represented without row goal, or by exposing the numbers as they are after applying the row goal.