Skip to content

Commit d3db704

Browse files
Merge pull request #2552 from MicrosoftDocs/main638755642420786460sync_temp
For protected branch, push strategy should use PR and merge to target branch method to work around git push error
2 parents f4f6610 + 32f9351 commit d3db704

File tree

2 files changed

+9
-7
lines changed

2 files changed

+9
-7
lines changed

data-explorer/kusto/query/best-practices.md

Lines changed: 1 addition & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -74,10 +74,7 @@ In order of importance:
7474
* When using the `where` query operator, the order in which you place the predicates, whether you use a single `where` operator, or multiple consecutive `where` operators,
7575
can have a significant effect on the query performance.
7676

77-
* Apply whole-shard predicates first. This means that predicates that use the [extent_id() function](extent-id-function.md) and [extent_tags() function](extent-tags-function.md)
78-
should be applied first. Also, when you have selective predicates that narrow the data down to specific partitions, they should be applied first.
79-
80-
* Then apply predicates that act upon `datetime` table columns. Kusto includes an efficient index on such columns,
77+
* Apply predicates that act upon `datetime` table columns first. Kusto includes an efficient index on such columns,
8178
often completely eliminating whole data shards without needing to access those shards.
8279

8380
* Then apply predicates that act upon `string` and `dynamic` columns, especially such predicates

data-explorer/kusto/query/extent-id-function.md

Lines changed: 8 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -10,12 +10,17 @@ monikerRange: "microsoft-fabric || azure-data-explorer"
1010

1111
> [!INCLUDE [applies](../includes/applies-to-version/applies.md)] [!INCLUDE [fabric](../includes/applies-to-version/fabric.md)] [!INCLUDE [azure-data-explorer](../includes/applies-to-version/azure-data-explorer.md)] [!INCLUDE [monitor](../includes/applies-to-version/monitor.md)] [!INCLUDE [sentinel](../includes/applies-to-version/sentinel.md)]
1212
13-
Returns a unique identifier that identifies the data shard ("extent") that the current record resides in.
13+
Returns a unique identifier that identifies the data shard ("extent") that the current record resides in at the time the query was run.
1414

1515
Applying this function to calculated data that isn't attached to a data shard returns an empty guid (all zeros).
1616

1717
> **Deprecated aliases:** extentid()
1818
19+
> [!CAUTION]
20+
>
21+
> The value returned by this function isn't guaranteed to remain stable over time. The system continuously performs data grooming operations in the background
22+
> and these can result with changes to existing extents and their IDs.
23+
1924
## Syntax
2025

2126
`extent_id()`
@@ -24,13 +29,13 @@ Applying this function to calculated data that isn't attached to a data shard re
2429

2530
## Returns
2631

27-
A value of type `guid` that identifies the current record's data shard,
32+
A value of type `guid` that identifies the current record's data shard at the time the query was run,
2833
or an empty guid (all zeros).
2934

3035
## Example
3136

3237
The following example shows how to get a list of all the data shards
33-
that have records from an hour ago with a specific value for the
38+
that currently have records from an hour ago with a specific value for the
3439
column `ActivityId`. It demonstrates that some query operators (here,
3540
the `where` operator, and also `extend` and `project`)
3641
preserve the information about the data shard hosting the record.

0 commit comments

Comments
 (0)