How does SQL Server estimate cardinality on nested loops index seek

I am trying to understand how SQL Server estimates cardinality on the below Stack Overflow database query Firstly, I create the index CREATE INDEX IX_PostId ON dbo.Comments ( PostId ) INCLUDE ( [Text] ) And here is the query: SELECT u.DisplayName, c.PostId, c.Text FROM Users u JOIN Comments c ON u.Reputation = c.PostId WHERE u.AccountId = 22547 The execution plan is here First of all, SQL Server scans the Clustered index on the users table to return the users that match the AccountId predicate. I can see that it uses this statistic: _WA_Sys_0000000E_09DE7BCC I can see that this user doesn't have a range high key, so SQL Server uses the avg_range rows and estimates 1 The seek predicate on the comments index seek is so Scalar Operator([StackOverflow2010].[dbo].[Users].[Reputation] as [u].[Reputation] represents the reputation value of the User(s) in the users table with the accountId of 22547 I can see three stats loaded in total : _WA_Sys_0000000E_09DE7BCC - Users.AccountId (Used to estimate the Clustered index seek predicate) IX_PostId - Comments.PostId (Used to estimate the Index seek predicate) _WA_Sys_0000000A_09DE7BCC - Users.Reputation (?) how does SQL server come up with the estimate on the index seek? It cannot know the reputation of accountId 22547 at compile time as the Account ID stat does not show that, so it cannot perform a lookup on the histogram for IX_PostId. I can see that the reputation stat is also loaded so does it use both somehow? This query was run against CE 150