diff --git a/data-explorer/kusto/query/best-practices.md b/data-explorer/kusto/query/best-practices.md
index a80b200acb..1ab5df839f 100644
--- a/data-explorer/kusto/query/best-practices.md
+++ b/data-explorer/kusto/query/best-practices.md
@@ -74,10 +74,7 @@ In order of importance:
 * 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,
   can have a significant effect on the query performance.
 
-* 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)
-  should be applied first. Also, when you have selective predicates that narrow the data down to specific partitions, they should be applied first.
-
-* Then apply predicates that act upon `datetime` table columns. Kusto includes an efficient index on such columns,
+* Apply predicates that act upon `datetime` table columns first. Kusto includes an efficient index on such columns,
   often completely eliminating whole data shards without needing to access those shards.
 
 * Then apply predicates that act upon `string` and `dynamic` columns, especially such predicates
diff --git a/data-explorer/kusto/query/extent-id-function.md b/data-explorer/kusto/query/extent-id-function.md
index 269c10a175..ee588936bb 100644
--- a/data-explorer/kusto/query/extent-id-function.md
+++ b/data-explorer/kusto/query/extent-id-function.md
@@ -10,12 +10,17 @@ monikerRange: "microsoft-fabric || azure-data-explorer"
 
 > [!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)]
 
-Returns a unique identifier that identifies the data shard ("extent") that the current record resides in.
+Returns a unique identifier that identifies the data shard ("extent") that the current record resides in at the time the query was run.
 
 Applying this function to calculated data that isn't attached to a data shard returns an empty guid (all zeros).
 
 > **Deprecated aliases:** extentid()
 
+> [!CAUTION]
+>
+> The value returned by this function isn't guaranteed to remain stable over time. The system continuously performs data grooming operations in the background
+> and these can result with changes to existing extents and their IDs.
+
 ## Syntax
 
 `extent_id()`
@@ -24,13 +29,13 @@ Applying this function to calculated data that isn't attached to a data shard re
 
 ## Returns
 
-A value of type `guid` that identifies the current record's data shard,
+A value of type `guid` that identifies the current record's data shard at the time the query was run,
 or an empty guid (all zeros).
 
 ## Example
 
 The following example shows how to get a list of all the data shards
-that have records from an hour ago with a specific value for the
+that currently have records from an hour ago with a specific value for the
 column `ActivityId`. It demonstrates that some query operators (here,
 the `where` operator, and also `extend` and `project`)
 preserve the information about the data shard hosting the record.