Introduce context options to control constantization/parameterization of parameterized collections #34344
Labels
area-perf
area-primitive-collections
area-query
closed-fixed
The issue has been fixed and is/will be included in the release indicated by the issue milestone.
type-enhancement
Milestone
Our current behavior parameterizes parameterized collections in SQL queries, typically via JSON. So
Where(b => ids.Contains(b.Id)
is translated on SQL Server via OPENJSON, andids
is encoded as a string parameter containing JSON array (done in #13617). However, although this allows having a single SQL query for different parameterized collections, it can lead to performance issues as the database isn't able to optimally plan for the query (see #32394).To mitigate this, we are going to introduce context options for controlling the default mode: parameterized (e.g. OPENJSON) or expansion to constants; this would allow users to choose the default behavior that fits their needs. In addition, it will be possible to override this default on a per-collection basis via EF.Constant (#31552) and EF.Parameter (#34345).
Note: in the future we may also want to introduce a 3rd mode alongside parameterization and constantization: bucketized constantization. We should design the context option APIs here in a way which would allow for this in a nice and consistent way.
The text was updated successfully, but these errors were encountered: