FrankChen021 commented on code in PR #20314: URL: https://github.com/apache/druid/pull/20314#discussion_r4052374116
########## docs/configuration/index.md: ########## @@ -1920,6 +1920,7 @@ The Druid SQL server is configured through the following properties on the Broke |`druid.sql.planner.maxNumericInFilters`|Max limit for the amount of numeric values that can be compared for a string type dimension when the entire SQL WHERE clause of a query translates to an [OR](../querying/filters.md#or) of [Bound filter](../querying/filters.md#bound-filter). By default, Druid does not restrict the amount of numeric Bound Filters on String columns, although this situation may block other queries from running. Set this property to a smaller value to prevent Druid from running queries that have prohibitively long segment processing times. The optimal limit requires some trial and error; we recommend starting with 100. Users who submit a query that exceeds the limit of `maxNumericInFilters` should instead rewrite their queries to use strings in the `WHERE` clause instead of numbers. For example, `WHERE someString IN (‘123’, ‘456’)`. If this value is disabled, `maxNumericInFilters` set through query context is ignored.|`-1` (disabled)| |`druid.sql.approxCountDistinct.function`|Implementation to use for the [`APPROX_COUNT_DISTINCT` function](../querying/sql-aggregations.md). Without extensions loaded, the only valid value is `APPROX_COUNT_DISTINCT_BUILTIN` (a HyperLogLog, or HLL, based implementation). If the [DataSketches extension](../development/extensions-core/datasketches-extension.md) is loaded, this can also be `APPROX_COUNT_DISTINCT_DS_HLL` (alternative HLL implementation) or `APPROX_COUNT_DISTINCT_DS_THETA`.<br /><br />Theta sketches use significantly more memory than HLL sketches, so you should prefer one of the two HLL implementations.|`APPROX_COUNT_DISTINCT_BUILTIN`| |`druid.sql.planner.enableSysQueriesTable`|**Experimental.** Whether to enable the [`sys.queries` table](../querying/sql-metadata-tables.md#queries-table), which provides information about currently running and recently completed SQL queries. Currently only queries from the Dart (MSQ) engine are shown.|false| +|`druid.sql.planner.maxPlanningTimeMs`|Maximum wall-clock time, in milliseconds, allowed for planning a SQL query on the Broker (the phase measured by the `sqlQuery/planningTimeMs` metric). When planning exceeds this budget, the in-progress Calcite planning is aborted and the query fails with an HTTP 504 `Query timeout` error. This guards the Broker against pathological queries, such as one with a very large `IN` filter, whose planning time can spike to tens of seconds and, under load, freeze the process. A value of `0` disables the timeout. Can be overridden per query with the `maxPlanningTimeMs` context parameter.|`0` (disabled)| Review Comment: To align with existing properties is a good way to think. But I would like to point out the fact that the dynamic broker configuration is a new feature added after the initial planner configuration. That's why we still see planner configuration properties are still there. Since now we have dynamic configuration supported, per-query settings should not be defined in planner configuration anymore. Otherwise it confuses users/operators because there are two ways to configure a property, one is via druid.sql.planner.*, the other is via: druid.query.default.context.* -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
