FrankChen021 commented on code in PR #20314: URL: https://github.com/apache/druid/pull/20314#discussion_r4062182625
########## 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: ## Follow-up assessment I rechecked the current head and found one additional P2 timeout race in `DirectStatement`: the watchdog can fire after the success-path check but before try-with-resources closes it, and the close path clears the interrupt without rechecking `timedOut`, so a plan can be returned after the deadline. I posted this issue inline in the current review. Reviewed 10 of 10 changed files. Static review only; no builds, tests, dependency installs, or formatters were run. <!-- mergelens:review --> -- 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]
