This is an automated cherry-pick of pingcap#19520

Signed-off-by: ti-chi-bot <[email protected]>

optimizer-fix-controls.md

@@ -58,3 +58,57 @@ SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON';
 - In some scenarios, when the `Probe` side of an `IndexJoin` operator contains a `Selection` operator, TiDB severely overestimates the row count of `IndexScan`. This might cause suboptimal query plans to be selected instead of `IndexJoin`.
 - To mitigate this issue, TiDB has introduced an improvement. However, due to potential query plan fallback risks, this improvement is disabled by default.
 - This variable controls whether to enable the preceding improvement.
+<<<<<<< HEAD
+=======
+
+### [`45132`](https://github.com/pingcap/tidb/issues/45132) <span class="version-mark">New in v7.4.0</span>
+
+- Default value: `1000`
+- Possible values: `[0, 2147483647]`
+- This variable sets the threshold for the optimizer's heuristic strategy to select access paths. If the estimated rows for an access path (such as `Index_A`) is much smaller than that of other access paths (default `1000` times), the optimizer skips the cost comparison and directly selects `Index_A`.
+- `0` means to disable this heuristic strategy.
+
+### [`45798`](https://github.com/pingcap/tidb/issues/45798) <span class="version-mark">New in v7.5.0</span>
+
+- Default value: `ON`
+- Possible values: `ON`, `OFF`
+- This variable controls whether Plan Cache is allowed to cache execution plans that access [generated columns](/generated-columns.md).
+
+### [`46177`](https://github.com/pingcap/tidb/issues/46177) <span class="version-mark">New in v6.5.6, v7.1.3 and v7.5.0</span>
+
+- Default value: `ON`
+- Possible values: `ON`, `OFF`
+- This variable controls whether the optimizer explores enforced plans during query optimization after finding an unenforced plan.
+
+### [`47400`](https://github.com/pingcap/tidb/issues/47400) <span class="version-mark">New in v8.4.0</span>
+
+- Default value: `ON`
+- Possible values: `ON`, `OFF`
+- Due to challenges in accurately estimating the number of qualified rows for each plan step in a query plan, the optimizer might estimate a smaller value for `estRows`. This variable controls whether to limit the minimum value of `estRows`.
+- `ON`: limits the minimum value of `estRows` to 1, which is the new behavior introduced in v8.4.0 and is consistent with other databases, such as Oracle and DB2.
+- `OFF`: disables the minimum row estimate limit, which maintains the behavior consistent with versions before v8.4.0. In this case, `estRows` might be zero.
+
+### [`52592`](https://github.com/pingcap/tidb/issues/52592) <span class="version-mark">New in v8.4.0</span>
+
+- Default value: `OFF`
+- Possible values: `ON`, `OFF`
+- This variable controls whether to disable the `Point Get` and `Batch Point Get` operators for query execution. The default value `OFF` means that `Point Get` and `Batch Point Get` can be used for query execution. If set to `ON`, the optimizer disables `Point Get` and `Batch Point Get`, forcing the selection of Coprocessor for query execution.
+- `Point Get` and `Batch Point Get` do not support column projection (that is, they cannot return only a subset of the columns), so in some scenarios, their execution efficiency might be lower than that of the Coprocessor, and setting this variable to `ON` can improve query performance. The following are recommended scenarios for setting this variable to `ON`:
+
+    - Wide tables with many columns, where only a few columns are queried.
+    - Tables with large JSON values, where the JSON column is not queried, or only a small portion of the JSON column is queried.
+
+### [`52869`](https://github.com/pingcap/tidb/issues/52869) <span class="version-mark">New in v8.1.0</span>
+
+- Default value: `OFF`
+- Possible values: `ON`, `OFF`
+- As stated in the **Note** of [Explain Statements Using Index Merge](/explain-index-merge.md#examples), if the optimizer can choose the single index scan method (other than full table scan) for a query plan, the optimizer will not automatically use index merge.
+- You can remove this limitation by enabling this fix control. Removing this limitation enables the optimizer to choose index merge automatically in more queries, but might cause the optimizer to ignore the optimal execution plans. Therefore, it is recommended to conduct sufficient tests on actual use cases before removing this limitation to make sure that it will not cause performance regressions.
+
+### [`54337`](https://github.com/pingcap/tidb/issues/54337) <span class="version-mark">New in v8.2.0</span>
+
+- Default value: `OFF`
+- Possible values: `ON`, `OFF`
+- Currently, the TiDB optimizer has limitations in deriving index ranges for complex conjunctive conditions where each conjunct comprises a list of ranges. This can be addressed by applying general range intersection.
+- You can remove this limitation by enabling this fix control, allowing the optimizer to handle complex range intersections. However, for conditions with a large number of conjuncts (more than 10), there is a slight risk of increased optimization time.
+>>>>>>> 29a7c8d136 (planner: update the fix-control doc (#19520))