Estimated Row for Constant Scan is 1 but Actuals is a lot more
I'm just getting started at reading execution plans so bear with me please 🙂 This is all new for me.
I see 2 Constant Scans that estimate 1 row will be returned but the actual is 13.000
The query performs ok for now (not much data) but I am intrigued by this big difference and want to become good at reading plans.
I read about Constant Scan and I see it as a data structure that is set up for what follows, the compute scalar. But why is the estimation so way off and is this a potential problem?
Added: I did a sp_updatestats to be sure.
The estimate of 1 row for the Constant Scan is per iteration of the nested loops join above it. SSMS shows per-iteration estimates for the inner side of a nested loops join. It shows a sum over all iterations in actual (post-execution) execution plans. This is confusing to most people when they start out reading plans.
Plan Explorer generally multiplies the estimated number of rows by the estimated number of executions below a nested loops join, to make it easier to compare estimated and actual plans. It is hard to be certain given the anonymized plan uploaded, but it seems Plan Explorer may not have applied this calculation correctly for the Merge Interval subtree in this case.
Is the expectation that the estimate number of rows is multiplied by the estimated number of executions. I observe that it stays at 1 (the behaviour of ssms).
Was the query plan above anonymized? I'll recheck but I did not press that button I believe in planexplorer. Maybe that way you can confirm if this was correct or incorrect behaviour of planexplorer.