Our initial work on precompiled queries (#25009) requires that queries be fully analyzable statically; that means the that entire LINQ query must be specified in one place - from the DbSet to the terminating operator which evaluates the query (e.g. ToList). In other words, it's impossible to precompile queries where LINQ operators are added dynamically.

The challenge with dynamic queries is that we don't know which materializers to pregenerate:

• Any change in the query output (projection) requiers a different materializer. For example, different Includes require different materializers.
• Other behavioral parameters change the materializer: split vs. single query, tracking/no tracking, buffering/no buffering.

It seems impractical to automatically pregenerate materializers for each and every one of the above options. Instead, we'd likely need to provide some sort of way for the user to tell us which materializers are actually needed. For example, they may use an API which contains a static version of the query, but projecting out the structure that their dynamic one would produce. At AOT-time, we'd recognize this and generate the appropriate materializer. At runtime, the query pipeline (1st part) would still fully run, but at the end would pick up out precompiled materializer instead of generating it.

This also implies annotating the entire query pipeline for AOT/trimming, which may be quite a tricky problem in itself.