Hi, we have a union query with a timeout of 20 secs when we check the sub query on historicals datasource 1 has timeout of 19 secs but datasource 2 has a timeout of less than 1 sec . Any possible reason why second datasource has less timeout value on historicals ? is the issue is on broker or historical

How are you checking the individual timeout values? There are two variants of union, both of which are parallelised afaik.

Yes I am Checking historical logs using the query id

i was wrong about my initial statement - table union queries are parallelised, top levels aren’t. From above statement, it seems that you are running the top level query, that’s getting sequentially executed. The reason that the second query only gets a second to execute is because the first one is taking 19 seconds.

i thought union queries subimt sub queries parallel for two datasources ? i have seen both are running parallel and have around 19 secs timeout but the actual query took around 3 secs to finish

there are two types of union queries https://druid.apache.org/docs/latest/querying/sql/#union-all. Top level runs sequentially, the table level runs parallely.

How can we get the query plan ? We get query plan only for sql queries

native json is the query plan

[Official Druid] GitHub in a RAG answer. code current 6/162024 It appears that your union query's subquery execution times on different datasources vary significantly—datasource 1 has a timeout of 19 seconds while datasource 2 has a timeout of less than 1 second. There are multiple factors that could contribute to this discrepancy: 1. Datasource Sizes and Schema Differences: Different datasources may vary significantly in size, which can impact query execution times. Larger datasources usually take longer to process compared to smaller ones. Furthermore, schema complexity and indexing also play crucial roles. Since the union of tables does not require identical schemas, some columns might be null and can affect performance. Refer to the following: > "If they do not fully match up, then columns that exist in one table but not another will be treated as if they contained all null values in the tables where they do not exist." - datasource.md (internal document) 1. Subquery Execution Method: Only certain types of subqueries can be processed in a streaming fashion, preventing resource usage limits from being exceeded. If one of the subqueries fits this criterion, it could explain why it completes significantly faster than the other, which might have different constraint handling that increases its execution time. Refer to: > "There is one exception: if the outer query is of type groupby, and has a datasource of type query that is itself another groupby, then subquery results can be processed in a streaming fashion." - query-execution.md (internal document) 1. Broker and Historical Server Load: The performance load on brokers and historical servers can also differ. If the broker or a particular historical server handling datasource 2 is less loaded or more optimized, it may complete the task more swiftly than the one processing datasource 1. 1. Hash Join Mechanism: Different datasources may also use different strategies for processing joins, especially with broadcast hash-joins, which could lead to varying execution times. Refer to: > "Join datasources are handled using a broadcast hash-join approach. The broker executes any subqueries that are inputs to the join, replacing them with inline datasources." - query-execution.md (internal document) Given these possibilities, the issue might reside either in the broker's handling of different subqueries or in the load and optimization differences among the historical servers processing the respective datasources. Sources: • Query Execution: query-execution.md (internal document) • Datasource: datasource.md (internal document)