pingcap · ti-chi-bot · Jul 9, 2026 · Jun 30, 2026 · Jun 30, 2026 · Jun 30, 2026
diff --git a/TOC.md b/TOC.md
@@ -66,6 +66,7 @@
       - [Replicate Data to Storage Services](/ticdc/ticdc-sink-to-cloud-storage.md)
     - [Manage Changefeeds](/ticdc/ticdc-manage-changefeed.md)
     - [Log Filter](/ticdc/ticdc-filter.md)
+    - [Table Routing](/ticdc/ticdc-table-routing.md)
     - [DDL Replication](/ticdc/ticdc-ddl.md)
     - [Bidirectional Replication](/ticdc/ticdc-bidirectional-replication.md)
   - Monitor and Alert
@@ -272,6 +273,7 @@
         - [Subquery Related Optimizations](/subquery-optimization.md)
         - [Column Pruning](/column-pruning.md)
         - [Decorrelation of Correlated Subquery](/correlated-subquery-optimization.md)
+        - [LATERAL Derived Tables](/lateral-derived-tables.md)
         - [Eliminate Max/Min](/max-min-eliminate.md)
         - [Predicates Push Down](/predicate-push-down.md)
         - [Partition Pruning](/partition-pruning.md)

diff --git a/br/backup-and-restore-storages.md b/br/backup-and-restore-storages.md
@@ -138,11 +138,33 @@ It is recommended that you configure access to S3 using either of the following
 </div>
 <div label="GCS" value="gcs">
 
-You can configure the account used to access GCS by specifying the access key. If you specify the `credentials-file` parameter, the authentication is performed using the specified `credentials-file`. Besides specifying the key in the URI, the following methods are also supported:
+You can configure the credentials used to access GCS in the following ways:
 
-- BR reads the file in the path specified by the environment variable `$GOOGLE_APPLICATION_CREDENTIALS`
-- BR reads the file `~/.config/gcloud/application_default_credentials.json`.
-- BR obtains the credentials from the metadata server when the cluster is running in GCE or GAE.
+- Method 1: Explicitly specify `credentials-file`
+
+    - If `credentials-file` points to a Service Account JSON file, BR and TiKV access GCS using this credential.
+    - If TiKV uses the `gcp_v2` external storage backend, `credentials-file` can also point to the `external_account` JSON used by Google Cloud WIF.
+
+- Method 2: Use Application Default Credentials (ADC)
+
+    - BR reads the file in the path specified by the environment variable `$GOOGLE_APPLICATION_CREDENTIALS`.
+    - BR reads the file `~/.config/gcloud/application_default_credentials.json`.
+    - When BR runs in GCE or GAE, it uses the credentials obtained from the metadata server.
+
+If you want TiKV to use GCS WIF or ADC, you need to enable the `gcp_v2` external storage backend. **Starting from v8.5.7, TiKV enables the `gcp_v2` external storage backend by default.** You can configure `gcp_v2` in the following ways:
+
+- Full backup and restore: set `[backup].gcp-v2-enable` to `true` in [TiKV Configuration File Descriptions](/tikv-configuration-file.md)
+- Log backup: set `[log-backup].gcp-v2-enable` to `true` in [TiKV Configuration File Descriptions](/tikv-configuration-file.md)
+
+The default values of the preceding two configuration items are both `true`. If you disable `gcp_v2`, TiKV continues to use the legacy GCS implementation. This implementation supports only Service Account JSON and does not support using WIF directly.
+
+> **Note:**
+>
+> The GCS JSON credentials explicitly passed to `gcp_v2` support only the `service_account` and `external_account` types. If you are using the `authorized_user` JSON generated by ADC and need TiKV to access GCS directly, it is recommended to set `--send-credentials-to-tikv=false` and configure ADC on each TiKV node. Otherwise, BR might send the `authorized_user` JSON to TiKV as an explicit credential, but `gcp_v2` does not accept this type of explicit JSON.
+
+> **Tip:**
+>
+> After `gcp_v2` is enabled, if GCS JSON credentials are not explicitly provided on the TiKV side, TiKV uses the Google Default Credentials flow. Therefore, when using ADC and setting `--send-credentials-to-tikv=false`, make sure that each TiKV node itself has a usable Google credentials environment.
 
 </div>
 <div label="Azure Blob Storage" value="azure">

diff --git a/correlated-subquery-optimization.md b/correlated-subquery-optimization.md
@@ -19,6 +19,8 @@ The disadvantage of this rewriting is that when the correlation is not lifted, t
 
 Therefore, when there are few external values, do not perform decorrelation, which might bring better execution performance. In this case, you can disable this optimization by using the [`NO_DECORRELATE`](/optimizer-hints.md#no_decorrelate) optimizer hint or by disabling the "subquery decorrelation" optimization rule in the [blocklist of optimization rules and expression pushdown](/blocklist-control-plan.md). In most cases, it is recommended to use the optimizer hint along with [SQL Plan Management](/sql-plan-management.md) to disable the decorrelation.
 
+Starting from v8.5.7, you can also use the system variable [`tidb_opt_enable_alternative_logical_plans`](/system-variables.md#tidb_opt_enable_alternative_logical_plans-new-in-v857) to optimize such scenarios. After you enable this variable, if the decorrelated candidate plan fails to generate an equivalent `IndexJoin` candidate plan with the same access direction as the original correlated subquery, the optimizer additionally retains a non-decorrelated candidate plan, evaluates both the decorrelated and non-decorrelated candidate plans, and selects the [execution plan](/explain-subqueries.md) with the lower cost.
+
 ## Example
 
 {{< copyable "sql" >}}