docs: document remote dynamic filter hint

docs/user-guide/protocols/http.md

@@ -92,6 +92,7 @@ Supported hints:
 | `append_mode` | Boolean | `false` | Enables [append-only mode](/reference/sql/create.md#create-an-append-only-table) for the table, which disables deduplication by primary key and supports duplicate rows. For InfluxDB line protocol writes, an explicit `append_mode=true` hint creates the table with `append_mode = 'true'` and `merge_mode = 'last_row'`. |
 | `merge_mode` | String | None | Sets the [merge mode](/reference/sql/create.md#create-a-table-with-merge-mode) for the table, e.g. `last_non_null`, `last_row`. For auto-created InfluxDB line protocol tables, this hint takes precedence over [`influxdb.default_merge_mode`](/user-guide/deployments-administration/configuration.md), which defaults to `last_non_null`. When `append_mode` is enabled, only `last_row` is allowed. |
 | `physical_table` | String | None | Specifies the physical table name for the [metric engine](/contributor-guide/datanode/metric-engine.md). |
+| `query.enable_remote_dynamic_filter_pushdown` | Boolean | `true` | Enables remote dynamic filter pushdown for SQL queries. Set it to `false` to disable Frontend-to-Datanode dynamic filter propagation for the current request. See [Remote dynamic filter pushdown](/user-guide/query-data/sql.md#remote-dynamic-filter-pushdown). |
 | `skip_wal` | Boolean | `false` | Skips WAL (Write-Ahead Log) writes for the table. |
 | `sst_format` | String | None | Sets the SST (Sorted String Table) file format for the table. Valid values: `flat`, `primary_key`. |
 | `trace_table_partitions` | Int | None | Override default partition number (16) of trace tables. Set to `0` or `1` to disable partitioning. |

docs/user-guide/query-data/sql.md

@@ -242,6 +242,35 @@ SELECT * FROM monitor ORDER BY ts ASC;
 SELECT * FROM monitor ORDER BY ts DESC;
 ```
 
+## Remote dynamic filter pushdown
+
+GreptimeDB enables remote dynamic filter pushdown by default for distributed SQL queries.
+It is mainly used by distributed join queries.
+When a join builds a runtime dynamic filter from one side of the join, the Frontend can propagate that filter to Datanodes so scans on the other side may prune data earlier.
+Some other operators, such as TopK (`ORDER BY ... LIMIT`), may also produce dynamic filters in eligible plans.
+
+This is a best-effort performance optimization and does not change query results.
+It only applies when the distributed query plan contains a dynamic filter that can be sent to remote scans.
+If the query plan has no dynamic filter, or if the filter cannot be encoded or applied safely, GreptimeDB runs the query without remote dynamic filter pushdown.
+
+To disable this optimization for one HTTP SQL request, set the `query.enable_remote_dynamic_filter_pushdown` hint to `false`:
+
+```bash
+curl -X POST \
+-H 'Content-Type: application/x-www-form-urlencoded' \
+-H 'x-greptime-hints: query.enable_remote_dynamic_filter_pushdown=false' \
+--data-urlencode "sql=SELECT m.* FROM monitor m JOIN host_info h ON m.host = h.host WHERE h.region = 'us-west'" \
+http://localhost:4000/v1/sql
+```
+
+The option defaults to `true`.
+Setting it to `false` disables Frontend-to-Datanode remote dynamic filter propagation for the current query only.
+It also applies to standalone deployments when the query is executed through the local Frontend-to-Datanode region query path.
+Currently, there is no persistent Frontend or Datanode configuration option for changing this default.
+It does not disable local dynamic filter optimizations inside one execution node.
+
+For more information about request hints, see [HTTP hints](/user-guide/protocols/http.md#hints).
+
 ## `CASE` Expression
 
 You can use the `CASE` statement to perform conditional logic within your queries.