I'm trying to understand some behavior I'm seeing in a query plan that's rather large and unruly. In particular, I'm looking at a Clustered Index Seek Operation containing a Scalar Operation within its Predicate. I suspect the Scalar operation is simply the aliasing of one of the tables (as described in Scalar Operator in Seek Predicate) as both columns are of the same type and this operation feeds into a Parallel Nested Loops (Left Outer Join) operator.
My question though is more about the Row Estimate coming in at 1 instead of a number closer to the Actual Number of Rows (~6.7 million). Is the Scalar Operation killing the optimizer's ability to estimate the rows properly? I assume so and also assume this is hurting my query execution plan from being optimal, but I don't really know for certain. Can someone confirm or refute my suspicions along with why?
Here's the operation in question:
Version: SQL Server 2012 Enterprise