Repo sync for protected branch

data-explorer/kusto/concepts/query-limits.md

@@ -121,7 +121,7 @@ holding significant data in memory. By default the limit is 5GB (per node), and
 
 <!-- csl -->
 ```kusto
-set maxmemoryconsumptionperiterator=68719476736;
+set maxmemoryconsumptionperiterator=16106127360;
 MyTable | summarize count() by Use
 ```
 
@@ -147,6 +147,8 @@ The TopNested operator has exceeded the memory budget during evaluation. Results
 
 If `maxmemoryconsumptionperiterator` is set multiple times, for example in both client request properties and using a `set` statement, the lower value applies.
 
+The maximum supported value for this request option is 32212254720 (30 GB).
+
 An additional limit that might trigger an `E_RUNAWAY_QUERY` partial query failure is a limit on the max accumulated size of
 strings held by a single operator. This limit cannot be overridden by the request option above:
 

data-explorer/kusto/management/request-limits-policy.md

@@ -25,7 +25,7 @@ The following limits are configurable:
 |--|--|--|--|--|
 | DataScope | `string` | The query's data scope. This value determines whether the query applies to all data or just the hot cache. | `All`, `HotCache`, or `null` | `query_datascope` |
 | MaxMemoryPerQueryPerNode | `long` | The maximum amount of memory (in bytes) a query can allocate. | [`1`, *50% of a single node's total RAM*] | `max_memory_consumption_per_query_per_node` |
-| MaxMemoryPerIterator | `long` | The maximum amount of memory (in bytes) a [query operator](../concepts/query-limits.md#limit-on-memory-consumed-by-query-operators-e_runaway_query) can allocate. | [`1`, *50% of a single node's total RAM*] | `maxmemoryconsumptionperiterator` |
+| MaxMemoryPerIterator | `long` | The maximum amount of memory (in bytes) a [query operator](../concepts/query-limits.md#limit-on-memory-consumed-by-query-operators-e_runaway_query) can allocate. | [`1`, Min(`32212254720`, *50% of a single node's total RAM*)] | `maxmemoryconsumptionperiterator` |
 | MaxFanoutThreadsPercentage | `int` | The percentage of threads on each node to fan out query execution to. When set to 100%, the cluster assigns all CPUs on each node. For example, 16 CPUs on a cluster deployed on Azure D14_v2 nodes. | [`1`, `100`] | `query_fanout_threads_percent` |
 | MaxFanoutNodesPercentage | `int` | The percentage of nodes on the cluster to fan out query execution to. Functions in a similar manner to `MaxFanoutThreadsPercentage`. | [`1`, `100`] | `query_fanout_nodes_percent` |
 | MaxResultRecords | `long` | The maximum number of records a request is allowed to return to the caller, beyond which the results are truncated. The truncation limit affects the final result of the query, as delivered back to the client. However, the truncation limit doesn't apply to intermediate results of subqueries, such as those that result from having cross-cluster references. | [`1`, `9223372036854775807`] | `truncationmaxrecords` |
@@ -37,7 +37,7 @@ The following limits are configurable:
 |--|--|--|--|--|
 | DataScope | `string` | The query's data scope. This value determines whether the query applies to all data or just the hot cache. | `All`, `HotCache`, or `null` | `query_datascope` |
 | MaxMemoryPerQueryPerNode | `long` | The maximum amount of memory (in bytes) a query can allocate. | [`1`, *50% of a single node's total RAM*] | `max_memory_consumption_per_query_per_node` |
-| MaxMemoryPerIterator | `long` | The maximum amount of memory (in bytes) a [query operator](../concepts/query-limits.md#limit-on-memory-consumed-by-query-operators-e_runaway_query) can allocate. | [`1`, *50% of a single node's total RAM*] | `maxmemoryconsumptionperiterator` |
+| MaxMemoryPerIterator | `long` | The maximum amount of memory (in bytes) a [query operator](../concepts/query-limits.md#limit-on-memory-consumed-by-query-operators-e_runaway_query) can allocate. | [`1`, Min(`32212254720`, *50% of a single node's total RAM*)] | `maxmemoryconsumptionperiterator` |
 | MaxFanoutThreadsPercentage | `int` | The percentage of threads on each node to fan out query execution to. When set to 100%, the Eventhouse assigns all CPUs on each node. For example, 16 CPUs on an eventhouse deployed on Azure D14_v2 nodes. | [`1`, `100`] | `query_fanout_threads_percent` |
 | MaxFanoutNodesPercentage | `int` | The percentage of nodes on the Eventhouse to fan out query execution to. Functions in a similar manner to `MaxFanoutThreadsPercentage`. | [`1`, `100`] | `query_fanout_nodes_percent` |
 | MaxResultRecords | `long` | The maximum number of records a request is allowed to return to the caller, beyond which the results are truncated. The truncation limit affects the final result of the query, as delivered back to the client. However, the truncation limit doesn't apply to intermediate results of subqueries, such as the results from having cross-eventhouse references. | [`1`, `9223372036854775807`] | `truncationmaxrecords` |

data-explorer/kusto/query/query-results-cache.md

@@ -68,9 +68,11 @@ Cached query results will have another row appended to that table:
   * `OriginalClientRequestId` - Specifies the original request's [ClientRequestId](../api/netfx/client-request-properties.md#named-properties).
   * `OriginalStartedOn` - Specifies the original request's execution start time.
 
+:::moniker range="azure-data-explorer"
 ## Query consistency
 
 Queries using [weak consistency](../concepts/query-consistency.md) can be processed on different cluster nodes. The cache isn't shared by cluster nodes, every node has a dedicated cache in its own private storage. Therefore, if two identical queries land on different nodes, the query will be executed and cached on both nodes. By setting query consistency to `affinitizedweakconsistency`, you can ensure that weak consistency queries that are identical land on the same query head, and thus increase the cache hit rate. This is not relevant when using [strong consistency](../concepts/query-consistency.md).
+::: moniker-end
 
 ## Management