FrankChen021 opened a new issue, #20326:
URL: https://github.com/apache/druid/issues/20326

   ### Affected versions
   
   Versions without a SQL planning timeout.
   
   ### Problem
   
   SQL query planning on the Broker is not bounded by the query execution 
timeout. A sufficiently complex SQL query can occupy a Broker request thread 
for seconds or minutes, and concurrent requests can exhaust the request-thread 
pool and make the Broker unresponsive.
   
   Large literal `IN` predicates are a demonstrated trigger. In a local 
planning-only benchmark on Druid 27 with Calcite 1.21.0, `maxLongUniform IN 
(...)` with 11,481 literals and `inSubQueryThreshold = Integer.MAX_VALUE` took 
approximately 7.16 seconds per plan. This is the known large-`IN` 
simplification problem tracked by #7904.
   
   The exact ordinary-datasource case is fast in newer releases: Druid 32.0.0 
with Calcite 1.37.0 measured approximately 25 ms per plan, and current master 
with Calcite 1.42.0 measured approximately 28 ms. However, this improvement 
comes from nullable datasource column typing avoiding the expensive Calcite 
path; it does not provide a general upper bound for other pathological planning 
shapes or genuinely non-nullable schemas.
   
   The earlier timeout issue #7957 was closed due to inactivity without adding 
an enforceable planning deadline.
   
   ### Expected behavior
   
   Druid should provide a configurable wall-clock timeout for SQL validation, 
authorization, and planning:
   
   - configurable globally and overridable through query context;
   - disabled by default for backward compatibility;
   - cancels Calcite planning through its supported cancellation mechanism;
   - returns a query-timeout response when the deadline is exceeded;
   - does not leak interruption state into pooled Broker request threads.
   
   Implementation is proposed in #20314.
   


-- 
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]

Reply via email to