Skip to content

Commit 77be862

Browse files
Merge pull request #2711 from MicrosoftDocs/main638911333555611644sync_temp
For protected branch, push strategy should use PR and merge to target branch method to work around git push error
2 parents 2638281 + 015c5f6 commit 77be862

File tree

2 files changed

+13
-11
lines changed

2 files changed

+13
-11
lines changed

data-explorer/kusto/management/data-export/create-alter-continuous.md

Lines changed: 7 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -3,7 +3,7 @@ title: .create or alter continuous-export
33
description: This article describes how to create or alter continuous data export.
44
ms.reviewer: yifats
55
ms.topic: reference
6-
ms.date: 07/30/2025
6+
ms.date: 08/18/2025
77
---
88
# .create or alter continuous-export
99

@@ -45,7 +45,9 @@ You must have at least [Database Admin](../../access-control/role-based-access-c
4545
| `intervalBetweenRuns` | `Timespan` | The time span between continuous export executions. Must be greater than 1 minute. |
4646
| `forcedLatency` | `Timespan` | An optional period of time to limit the query to records ingested before a specified period relative to the current time. This property is useful if, for example, the query performs some aggregations or joins, and you want to make sure all relevant records have been ingested before running the export. |
4747
| `sizeLimit` | `long` | The size limit in bytes of a single storage artifact written before compression. Valid range: 100 MB (default) to 1 GB. |
48-
| `distributed` | `bool` | Disable or enable distributed export. Setting to false is equivalent to `single` distribution hint. Default is true. |
48+
| `distributed` | `bool` | Disable or enable distributed export. Setting to false is equivalent to `single` distribution hint. Default is `true`. |
49+
| `distribution` | `string` | Distribution hint (`single`, `per_node`, `per_shard`). See more details in [Distribution settings](export-data-to-an-external-table.md#distribution-settings). Default is `per_node` |
50+
| `distributionKind` | `string` | Optionally switches to uniform distribution when the external table is partitioned by string partition. Valid values are `uniform` or `default`. See more details in [Distribution settings](export-data-to-an-external-table.md#distribution-settings) |
4951
| `parquetRowGroupSize` | `int` | Relevant only when data format is Parquet. Controls the row group size in the exported files. Default row group size is 100,000 records. |
5052
| `managedIdentity` | `string` | The managed identity for which the continuous export job runs. The managed identity can be an object ID, or the `system` reserved word. For more information, see [Use a managed identity to run a continuous export job](continuous-export-with-managed-identity.md#use-a-managed-identity-to-run-a-continuous-export-job). |
5153
| `isDisabled` | `bool` | Disable or enable the continuous export. Default is false. |
@@ -58,7 +60,9 @@ You must have at least [Database Admin](../../access-control/role-based-access-c
5860
| `intervalBetweenRuns` | `Timespan` | The time span between continuous export executions. Must be greater than 1 minute. |
5961
| `forcedLatency` | `Timespan` | An optional period of time to limit the query to records ingested before a specified period relative to the current time. This property is useful if, for example, the query performs some aggregations or joins, and you want to make sure all relevant records have been ingested before running the export. |
6062
| `sizeLimit` | `long` | The size limit in bytes of a single storage artifact written before compression. Valid range: 100 MB (default) to 1 GB. |
61-
| `distributed` | `bool` | Disable or enable distributed export. Setting to false is equivalent to `single` distribution hint. Default is true. |
63+
| `distributed` | `bool` | Disable or enable distributed export. Setting to false is equivalent to `single` distribution hint. Default is `true`. |
64+
| `distribution` | `string` | Distribution hint (`single`, `per_node`, `per_shard`). See more details in [Distribution settings](export-data-to-an-external-table.md#distribution-settings). Default is `per_node` |
65+
| `distributionKind` | `string` | Optionally switches to uniform distribution when the external table is partitioned by string partition. Valid values are `uniform` or `default`. See more details in [Distribution settings](export-data-to-an-external-table.md#distribution-settings) |
6266
| `parquetRowGroupSize` | `int` | Relevant only when data format is Parquet. Controls the row group size in the exported files. Default row group size is 100,000 records. |
6367
| `isDisabled` | `bool` | Disable or enable the continuous export. Default is false. |
6468

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

Lines changed: 6 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -3,7 +3,7 @@ title: Create materialized view
33
description: This article describes how to create materialized views.
44
ms.reviewer: yifats
55
ms.topic: reference
6-
ms.date: 02/11/2025
6+
ms.date: 08/18/2025
77
---
88

99
# .create materialized-view
@@ -99,12 +99,10 @@ The lookback period is always relative to a `datetime` column in the materialize
9999
* **Default:** Relative to the record's [ingestion_time()](../../query/ingestion-time-function.md) in the source table. Records are deduplicated only against records which are ingested to the source table after a lookback period relative to the current records. This kind of lookback is valid only for `arg_max`, `arg_min`, or `take_any` materialized views, and only for views that preserve ingestion time. For more information, see [Materialized views limitations and known issues](materialized-views-limitations.md).
100100
You can configure the default option by setting the `lookback` property without the `lookback_column` property.
101101

102-
* **lookback_column (preview):** Relative to a `datetime` column in the materialized view. The lookback is explicitly specified in the materialized view definition, using the `lookback_column` property. For more information, see [Known limitations](#known-limitations). You can configure the lookback column option by setting both the `lookback` and the `lookback_column` properties.
103-
104-
#### Known limitations
105-
106-
* Once a `lookback_column` is defined, you can't change its value.
107-
* Using a `lookback_column` can lead to duplicates if the column has `datetime(null)` values. In such cases, for a given combination of group-by keys, the view might end up with one record having a `datetime(null)` value and another with a non-null value.
102+
* **lookback_column:** Relative to a `datetime` column in the materialized view. The lookback is explicitly specified in the materialized view definition, using the `lookback_column` property. You can configure the lookback column option by setting both the `lookback` and the `lookback_column` properties.
103+
* There is no need to define a `lookback_column` on a `datetime` column, which is one of the group-by keys of the materialized view aggregation. A `lookback_column` is only helpful if it references another `datetime` column, which is not part of group-by keys.
104+
* Once a `lookback_column` is defined, you can't change its value.
105+
* Using a `lookback_column` can lead to duplicates if the column has `datetime(null)` values. In such cases, for a given combination of group-by keys, the view might end up with one record having a `datetime(null)` value and another with a non-null value.
108106

109107
### Create materialized view over materialized view
110108

@@ -309,7 +307,7 @@ The following aggregation functions are supported:
309307
>
310308
> 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.
311309
312-
* **Define a lookback period**: If applicable to your scenario, adding a `lookback` property can significantly improve query performance. For details, see [Supported properties](#supported-properties).
310+
* **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).
313311

314312
* **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.
315313

0 commit comments

Comments
 (0)