You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Use case
Currently there is max_execution_time setting, that can be set in subqueries. But it makes it hard to use this setting with distributed sub-queries, as it is likely that timeout will be reached before distributed subquery finished.
Describe the solution you'd like
Add max_execution_time_leaf settings similar to the other restrictions on query complexity that only apply to distributed sub queries.
Describe alternatives you've considered
It is possible to workaround this using features like view, or dyanmically with cluster(view()) to set manually timeout in the subquery since we have control over them and they are not generated internally. But it is much less handy than simply using distributed tables, and for some reason other max_* seettings have a leaf version.
The text was updated successfully, but these errors were encountered:
Use case
Currently there is max_execution_time setting, that can be set in subqueries. But it makes it hard to use this setting with distributed sub-queries, as it is likely that timeout will be reached before distributed subquery finished.
Describe the solution you'd like
Add max_execution_time_leaf settings similar to the other restrictions on query complexity that only apply to distributed sub queries.
Describe alternatives you've considered
It is possible to workaround this using features like view, or dyanmically with cluster(view()) to set manually timeout in the subquery since we have control over them and they are not generated internally. But it is much less handy than simply using distributed tables, and for some reason other max_* seettings have a leaf version.
The text was updated successfully, but these errors were encountered: