What Changed?

EF Core 11 (preview 3) prunes reference navigation JOINs from split query collection queries. Previously, if you had multiple Include calls on reference navigations, each collection query dragged along all those JOINs and ORDER BY columns—even though only the parent's primary key was needed to correlate results.

Before and After

Consider:

var result = context.Blogs
    .Include(x => x.BlogType) // reference navigation
    .Include(x => x.Posts)    // collection navigation
    .AsSplitQuery()
    .ToList();

In EF Core 10, this produced two queries. The second query (for Posts) looked like:

SELECT [p].[Id], [p].[BlogId], [p].[Title], [b].[Id], [b0].[Id]
FROM [Blogs] AS [b]
LEFT JOIN [BlogType] AS [b0] ON [b].[BlogTypeId] = [b0].[Id]
INNER JOIN [Post] AS [p] ON [b].[Id] = [p].[BlogId]
ORDER BY [b].[Id], [b0].[Id];

The BlogType JOIN and its Id in SELECT/ORDER BY are unnecessary—only the blog's PK is needed to match posts.

In EF Core 11, that second query becomes:

SELECT [p].[Id], [p].[BlogId], [p].[Title], [b].[Id]
FROM [Blogs] AS [b]
INNER JOIN [Post] AS [p] ON [b].[Id] = [p].[BlogId]
ORDER BY [b].[Id];

Clean. No extra JOINs, no extraneous columns.

Benchmarks

Benchmarks comparing .NET 10 (EF Core 10) vs .NET 11 (EF Core 11) with 5,000 blogs and 5 posts each (using SQLite):

MethodRuntimeMeanAllocated
SplitQuery.NET 10.068.53 ms33.35 MB
SplitQuery.NET 11.062.07 ms30.15 MB

That's a ~9.5% reduction in execution time and ~9.6% less memory allocation. The improvement scales with the number of reference navigations included.

Why It Matters

Split queries are the go-to workaround for the cartesian explosion problem when loading multiple collections. But they came with overhead: each additional reference navigation added a JOIN per collection query. EF Core 11 eliminates that overhead, making split queries closer to hand-optimized SQL.

What to Do

  • Update to .NET 11 preview 3 or later.
  • If you use AsSplitQuery() with multiple Include calls on reference navigations, you'll get the speedup automatically.
  • If you avoided split queries due to performance concerns, retest with EF Core 11.

Caveats

  • The benchmark compares .NET 10 vs .NET 11, so some gains might come from runtime improvements, not just EF changes. But the EF issue is clear.
  • Split queries still involve multiple roundtrips and are not atomic. Use them when the cartesian explosion is worse than the overhead.

Resources