From 908b62040c168ce7f3e54da29329dfd70079089f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Erhan=20Alanku=C5=9F?= Date: Wed, 6 Apr 2022 15:24:06 +0300 Subject: [PATCH 1/2] Add What MARS abbreviation stands for --- entity-framework/core/performance/efficient-querying.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/entity-framework/core/performance/efficient-querying.md b/entity-framework/core/performance/efficient-querying.md index e3113c4e63..f7dbe6fe89 100644 --- a/entity-framework/core/performance/efficient-querying.md +++ b/entity-framework/core/performance/efficient-querying.md @@ -163,7 +163,7 @@ If your queries return just a few results, then you probably don't have to worry In certain situations, EF will itself buffer the resultset internally, regardless of how you evaluate your query. The two cases where this happens are: * When a retrying execution strategy is in place. This is done to make sure the same results are returned if the query is retried later. -* When [split query](xref:core/querying/single-split-queries) is used, the resultsets of all but the last query are buffered - unless MARS is enabled on SQL Server. This is because it is usually impossible to have multiple query resultsets active at the same time. +* When [split query](xref:core/querying/single-split-queries) is used, the resultsets of all but the last query are buffered - unless Multiple Active Result Sets(MARS) is enabled on SQL Server. This is because it is usually impossible to have multiple query resultsets active at the same time. Note that this internal buffering occurs in addition to any buffering you cause via LINQ operators. For example, if you use on a query and a retrying execution strategy is in place, the resultset is loaded into memory *twice*: once internally by EF, and once by . From 60d09193f2eb511c6bb77cdde27517a0fa5be6e4 Mon Sep 17 00:00:00 2001 From: Shay Rojansky Date: Thu, 7 Apr 2022 12:11:10 +0300 Subject: [PATCH 2/2] Update entity-framework/core/performance/efficient-querying.md --- entity-framework/core/performance/efficient-querying.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/entity-framework/core/performance/efficient-querying.md b/entity-framework/core/performance/efficient-querying.md index f7dbe6fe89..ae5e7d8bf0 100644 --- a/entity-framework/core/performance/efficient-querying.md +++ b/entity-framework/core/performance/efficient-querying.md @@ -163,7 +163,7 @@ If your queries return just a few results, then you probably don't have to worry In certain situations, EF will itself buffer the resultset internally, regardless of how you evaluate your query. The two cases where this happens are: * When a retrying execution strategy is in place. This is done to make sure the same results are returned if the query is retried later. -* When [split query](xref:core/querying/single-split-queries) is used, the resultsets of all but the last query are buffered - unless Multiple Active Result Sets(MARS) is enabled on SQL Server. This is because it is usually impossible to have multiple query resultsets active at the same time. +* When [split query](xref:core/querying/single-split-queries) is used, the resultsets of all but the last query are buffered - unless MARS (Multiple Active Result Sets) is enabled on SQL Server. This is because it is usually impossible to have multiple query resultsets active at the same time. Note that this internal buffering occurs in addition to any buffering you cause via LINQ operators. For example, if you use on a query and a retrying execution strategy is in place, the resultset is loaded into memory *twice*: once internally by EF, and once by .