Why Execution Plan Operator Read More Rows Than Available? – Interview Question of the Week #255

Question: Why can an execution plan display more actual rows than expected? The expected count is an estimate, not a limit on the real rows. “33 of 21” means actual versus estimated cardinality, not 33 rows arriving from an input containing only 21.

A health-check client asked about this display in an actual plan. The original WideWorldImporters query makes the distinction visible:

SELECT *
FROM WideWorldImporters.Sales.OrderLines
WHERE UnitPrice = 36.00;

Statistics and the cardinality-estimation model help the optimizer predict how many rows will satisfy UnitPrice = 36.00. Execution still returns all qualifying rows; the estimate doesn’t tell SQL Server to stop at 21.

In this capture, 33 divided by approximately 21 explains the percentage. This isn’t necessarily a serious estimation error. Assess whether it led to a poor join choice, inadequate memory grant or other measurable cost.

A different property, Number of Rows Read, can exceed rows returned because an operator reads candidates and then applies a predicate. Repeated executions of an inner operator can also revisit rows. Those are different questions from the original actual-versus-estimated display.

Updating stale or poorly sampled statistics can help an estimate, but isn’t a universal fix. Data distribution, parameter values and the estimation model can also matter. Don’t update everything just because a percentage exceeds 100.

The two original captures are sharp and useful, so they remain beside their exact query. Your current sample database may produce different counts or plan shapes. Related: persisting the statistics sample percentage.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.