Description
From this conversation:
Introduce a new section on the page focused entirely on replanning. This would provide some context about the purpose of replanning. Something like "Plan caching is an important optimization which avoids repeated work to select and construct the winning query plan. However, there are scenarios in which the cached plan does not perform well for instances of the query shape with different parameter values, or where the performance of the plan becomes worse as the data changes. The system implements a form of automatic regression detection in order to try to detect when the performance of a cached plan has degraded, in which case the cache entry is evicted and the query is planned from scratch. This mechanism is known as replanning. When it kicks in, it is indicated in the query's log line with 'replanned:true' and a 'replanReason' field."
From there, we would go on to describe that replanning kicks in not only when we detect degraded plan performance, but also if the cached plan has a blocking sort stage that fails due to exceeding its memory limit (when spilling is not allowed).
Attachments
Issue Links
- is related to
-
DOCS-12651 Clarify triggering events for the query replanning mechanism
-
- Closed
-