Repo sync for protected branch

data-explorer/kusto/management/materialized-views/materialized-view-alter-lookback.md

@@ -69,5 +69,7 @@ The following example removes the lookback period of the materialized view, `MyV
 * [Materialized views lookback period](materialized-view-create.md#lookback-period)
 * [Materialized views](materialized-view-overview.md)
 * [Materialized views use cases](materialized-view-use-cases.md)
+* [Materialized views optimization](materialized-views-optimization.md)
 * [.create materialized-view](materialized-view-create.md)
 * [.alter materialized-view](materialized-view-alter.md)
+

data-explorer/kusto/management/materialized-views/materialized-view-alter.md

@@ -83,5 +83,6 @@ The following command modifies the query definition of materialized view MyView:
 
 * [Materialized views](materialized-view-overview.md)
 * [Materialized views use cases](materialized-view-use-cases.md)
+* [Materialized views optimization](materialized-views-optimization.md)
 * [.create materialized-view](materialized-view-create.md)
-* [.create-or-alter materialized-view](materialized-view-create-or-alter.md)
+* [.create-or-alter materialized-view](materialized-view-create-or-alter.md)

data-explorer/kusto/management/materialized-views/materialized-view-create-or-alter.md

@@ -88,5 +88,6 @@ For more information, see the [Query parameter](materialized-view-create.md#quer
 
 * [Materialized views](materialized-view-overview.md)
 * [Materialized views use cases](materialized-view-use-cases.md)
+* [Materialized views optimization](materialized-views-optimization.md)
 * [.create materialized-view](materialized-view-create.md)
-* [.alter materialized-view](materialized-view-alter.md)
+* [.alter materialized-view](materialized-view-alter.md)

data-explorer/kusto/management/materialized-views/materialized-view-create.md

@@ -284,92 +284,6 @@ The following aggregation functions are supported:
 * [`percentile`, `percentiles`](../../query/percentiles-aggregation-function.md)
 * [`tdigest`](../../query/tdigest-aggregation-function.md)
 
-### Performance tips
-
-* **Use a datetime group-by key**: Materialized views that have a `datetime` column as one of their group-by keys is more efficient than those that don't. The reason is that some optimizations can be applied only when there's a datetime group-by key. If adding a datetime group-by key doesn't change the semantics of your aggregation, we recommend that you add it. You can do this only if the `datetime` column is *immutable* for each unique entity.
-
-  For example, in the following aggregation:
-
-  ```kusto
-      SourceTable | summarize take_any(*) by EventId
-  ```
-
-  If `EventId` always has the same `Timestamp` value, and therefore adding `Timestamp` doesn't change the semantics of the aggregation, it's better to define the view as:
-
-  ```kusto
-      SourceTable | summarize take_any(*) by EventId, Timestamp
-  ```
-
-  > [!TIP]
-  > Late-arriving data in a datetime group-by key can have a negative impact on the materialized view's performance. For example, assume that a materialized view uses `bin(Timestamp, 1d)` as one of its group-by keys, and newly ingested records to the source table have old `Timestamp` values. These records might negatively affect the materialized view.
-  >
-  > If you expect late arriving records ingested to the source table, adjust the caching policy of the materialized view accordingly. For example, if records with Timestamp of six months ago are expected to be ingested to the source table, the materialization process needs to scan the materialized view for the previous six months. If this period is in cold cache, materialization experiences cache misses which have a negative impact on the performance of the view.
-  >
-  > If such late arriving records aren't expected, we recommend that in the materialized view query. Either filter these records out or normalize their timestamp values to the current time.
-
-* **Define a lookback period**: If applicable to your scenario, adding a `lookback` property can significantly improve query performance. For details, see [Lookback period](#lookback-period).  
-
-* **Add columns frequently used for filtering as group-by keys**: Materialized view queries are optimized when they're filtered by one of the materialized view's group-by keys. If you know that your query pattern will often filter by a column that's immutable according to a unique entity in the materialized view, include it in the materialized view's group-by keys.
-
-    For example, a materialized view exposes `arg_max` by a `ResourceId` value that is often filtered by `SubscriptionId`. Assuming that a `ResourceId` value always belongs to the same `SubscriptionId` value, define the materialized view query as:
-
-    ```kusto
-    .create materialized-view ArgMaxResourceId on table FactResources
-    {
-        FactResources | summarize arg_max(Timestamp, *) by SubscriptionId, ResourceId 
-    }
-    ```
-
-    The preceding definition is preferable over the following:
-
-    ```kusto
-    .create materialized-view ArgMaxResourceId on table FactResources
-    {
-        FactResources | summarize arg_max(Timestamp, *) by ResourceId 
-    }
-    ```
-
-* **Use update policies where appropriate**: The materialized view can include transformations, normalizations, and lookups in dimension tables. However, we recommend that you move these operations to an [update policy](../update-policy.md). Leave only the aggregation for the materialized view.
-
-    For example, it's better to define the following update policy:
-
-    ```kusto
-    .alter-merge table Target policy update 
-    @'[{"IsEnabled": true, 
-        "Source": "SourceTable", 
-        "Query": 
-            "SourceTable 
-            | extend ResourceId = strcat('subscriptions/', toupper(SubscriptionId), '/', resourceId)", 
-            | lookup DimResources on ResourceId
-            | mv-expand Events
-        "IsTransactional": false}]'  
-    ```
-
-    And define the following materialized view:
-
-    ```kusto
-    .create materialized-view Usage on table Events
-    {
-        Target 
-        | summarize count() by ResourceId 
-    }
-    ```
-
-    The alternative, of including the update policy as part of the materialized view query, might perform worse and therefore not recommended:
-
-    ```kusto
-    .create materialized-view Usage on table SourceTable
-    {
-        SourceTable
-        | extend ResourceId = strcat('subscriptions/', toupper(SubscriptionId), '/', resourceId)
-        | lookup DimResources on ResourceId
-        | mv-expand Events
-        | summarize count() by ResourceId
-    }
-    ```
-
-> [!TIP]
-> If you require the best query time performance, but you can tolerate some data latency, use the [materialized_view() function](../../query/materialized-view-function.md).
 
 ### Backfill a materialized view
 
@@ -555,6 +469,7 @@ If the cancellation isn't finished within 10 minutes, `CancellationState` indica
 
 * [Materialized views](materialized-view-overview.md)
 * [Materialized views use cases](materialized-view-use-cases.md)
+* [Materialized views optimization](materialized-views-optimization.md)
 * [.alter materialized-view](materialized-view-alter.md)
 * [.drop materialized-view](materialized-view-drop.md)
-* [.show materialized-view(s)](materialized-view-show-command.md)
+* [.show materialized-view(s)](materialized-view-show-command.md)

data-explorer/kusto/management/materialized-views/materialized-view-overview.md

@@ -106,7 +106,7 @@ There are 2 ways to query a materialized view:
 
 When querying the entire view, the materialized part is combined with the `delta` during query time. This includes aggregating the `delta` and joining it with the materialized part.
 
-* Querying the entire view performs better if the query includes filters on the group by keys of the materialized view query. See more tips about how to create your materialized view, based on your query pattern, in the [`.create materialized-view` performance tips](materialized-view-create.md#performance-tips) section.
+* Querying the entire view performs better if the query includes filters on the group by keys of the materialized view query. See more tips about how to create your materialized view, based on your query pattern, in [Materialized views optimization](materialized-views-optimization.md).
 * The query optimizer chooses summarize/join strategies that are expected to improve query performance. For example, the decision on whether to [shuffle](../../query/shuffle-query.md) the query is based on number of records in `delta` part. The following [client request properties](../../api/rest/request-properties.md) provide some control over the optimizations applied. You can test these properties with your materialized view queries and evaluate their impact on queries performance.
 
 |Client request property name|Type|Description|
@@ -157,7 +157,7 @@ When querying the materialized part of the view, the return value depends on the
 The main contributors that can impact a materialized view health are:
 
 :::moniker range="azure-data-explorer"
-* **Cluster resources:** Like any other process running on the cluster, materialized views consume resources (CPU, memory) from the cluster. If the cluster is overloaded, adding materialized views to it may cause a degradation in the cluster's performance. Monitor your cluster's health using [cluster health metrics](/azure/data-explorer/using-metrics#cluster-metrics). [Optimized autoscale](/azure/data-explorer/manage-cluster-horizontal-scaling#optimized-autoscale-recommended-option) currently doesn't take materialized views health under consideration as part of autoscale rules.
+* **Cluster resources:** Like any other process running on the cluster, materialized views consume resources (CPU, memory) from the cluster. If the cluster is overloaded, adding materialized views to it may cause a degradation in the cluster's performance. Monitor your cluster's health using [cluster health metrics](/azure/data-explorer/monitor-data-explorer-reference#supported-metrics-for-microsoftkustoclusters). [Optimized autoscale](/azure/data-explorer/manage-cluster-horizontal-scaling#optimized-autoscale-recommended-option) currently doesn't take materialized views health under consideration as part of autoscale rules.
   * The [materialization process](#how-materialized-views-work) is limited by the amount of memory and CPU it can consume. These limits are defined, and can be changed, in the [materialized views workload group](../workload-groups.md#materialized-views-workload-group).
 ::: moniker-end
 
@@ -169,7 +169,7 @@ The main contributors that can impact a materialized view health are:
 * **Number of materialized views in cluster:** The above considerations apply to each individual materialized view defined in the cluster. Each view consumes its own resources, and many views compete with each other on available resources. While there are no hard-coded limits to the number of materialized views in a cluster, the cluster may not be able to handle all materialized views, when there are many defined. The [capacity policy](../capacity-policy.md#materialized-views-capacity-policy) can be adjusted if there is more than a single materialized view in the cluster. Increase the value of `ClusterMinimumConcurrentOperations` in the policy to run more materialized views concurrently.
 ::: moniker-end
 
-* **Materialized view definition**: The materialized view definition must be defined according to query best practices for best query performance. For more information, see [create command performance tips](materialized-view-create.md#performance-tips).
+* **Materialized view definition**: The materialized view definition must be defined according to query best practices for best query performance. For more information, see [create command performance tips](materialized-views-optimization.md).
 
 ## Materialized view over materialized view
 
@@ -183,6 +183,7 @@ A materialized view can be created over another materialized view if the source
 * [Materialized views policies](materialized-view-policies.md)
 * [Materialized views limitations and known issues](materialized-views-limitations.md)
 * [Materialized views use cases](materialized-view-use-cases.md)
+* [Materialized views optimization](materialized-views-optimization.md)
 * [Monitor materialized views](materialized-views-monitoring.md)
 * [`.create materialized view`](materialized-view-create.md)
 * [`.alter materialized-view`](materialized-view-alter.md)

data-explorer/kusto/management/materialized-views/materialized-view-purge.md

@@ -45,4 +45,5 @@ MV | where avg_Duration > 1h
 
 ## Related content
 
-* [Materialized views](materialized-view-overview.md)
+* [Materialized views](materialized-view-overview.md)
+* [Materialized views optimization](materialized-views-optimization.md)

data-explorer/kusto/management/materialized-views/materialized-view-use-cases.md

@@ -139,6 +139,7 @@ Materialized views and update policies work differently and serve different use
 * [Materialized views policies](materialized-view-policies.md)
 * [Materialized views limitations and known issues](materialized-views-limitations.md)
 * [Monitor materialized views](materialized-views-monitoring.md)
+* [Materialized views optimization](materialized-views-optimization.md)
 * [`.create materialized view`](materialized-view-create.md)
 * [`.alter materialized-view`](materialized-view-alter.md)
 * [`{.disable | .enable} materialized-view`](materialized-view-enable-disable.md)

data-explorer/kusto/management/materialized-views/materialized-views-limitations.md

@@ -23,7 +23,6 @@ ms.date: 06/03/2026
 * The source table of a materialized view can't be a table with a [restricted view access policy](../restricted-view-access-policy.md).
 * A materialized view can't be created on top of another materialized view, unless the first materialized view is of type `take_any(*)` aggregation. See [materialized view over materialized view](materialized-view-overview.md#materialized-view-over-materialized-view).
 * Materialized views can't be defined over [external tables](../../query/schema-entities/external-tables.md).
-* Materialized views cannot be queried with [cursors](../../query/database-cursor.md)
 
 > [!WARNING]
 >
@@ -58,11 +57,12 @@ ms.date: 06/03/2026
 
 ## Other
 
-* [Cursor functions](../database-cursor.md#cursor-functions) can't be used on top of materialized views.
+* [Cursor functions](../../query/database-cursor.md#cursor-functions) can't be used on top of materialized views.
 * Continuous export from a materialized view isn't supported.
 
 ## Related content
 
 * [Materialized views](materialized-view-overview.md)
 * [Materialized views use cases](materialized-view-use-cases.md)
+* [Materialized views optimization](materialized-views-optimization.md)
 * [Monitor materialized views](materialized-views-monitoring.md)