Smit Patel

> But in second Join compiler says that it can't infer type and I can't specify needed generic type in this case because that is anonymous type. Or I can?...

See https://docs.microsoft.com/en-us/ef/core/querying/complex-query-operators#left-join

Sorry missed message earlier. I tried running above on EF Core 5.0 preview7 and it is generating correct SQL. It is throwing some exception for 3.1. So it may be...

It is not an optimization, it is literally translation of query. If you ask for first user with Order collection included, we generate SQL which perform join between first user...

> Why do both single and first produce the same SQL? They don't produce same SQL either. The LIMIT in both queries is different number. Now I realized why perf...

From T-SQL perspective it is valid SQL. You can use any of the top level aliases from table inside any level nesting in the projection subqueries. So this could be...

The page needs to go away.

DISTINCT ON and ROW_NUMBER are different things. And of course ROW_NUMBER is slow because it assigns number to each row, not just drop duplicated one. - While nowhere written in...

As I mentioned in my original comment that issue is in backlog, here is the link https://github.com/dotnet/efcore/issues/12088 Postgre could consider an alternate translation of it based on "Distinct ON" and...

Based on above error message, a simple GroupBy - Group.FirstOrDefault clears pre-processing pipeline. So postgre could translate it outside of EF Core. If translation would be same then of course...