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
There is currently no way to cancel a distributed INSERT once it lands into the distribution queue.
This is a problem for us when more than one INSERT SELECT queries are accidentally executed - the distribution queue grows very large and is processed very slowly, the table ends up with duplicate rows and there is no way to stop this process until all the queues finish processing.
Basically, a distributed insert should look like a mutation from a UX perspective. (Our ETL process is ALTER TABLE DELETE followed by INSERT SELECT. The DELETE step works great, but the INSERT is not controllable at the moment and interacts poorly with the rest of the pipeline. Ideally there should be a way to cancel an INSERT SELECT mutation or wait until it finishes.)
The text was updated successfully, but these errors were encountered:
There is currently no way to cancel a distributed INSERT once it lands into the distribution queue.
This is a problem for us when more than one INSERT SELECT queries are accidentally executed - the distribution queue grows very large and is processed very slowly, the table ends up with duplicate rows and there is no way to stop this process until all the queues finish processing.
Basically, a distributed insert should look like a mutation from a UX perspective. (Our ETL process is ALTER TABLE DELETE followed by INSERT SELECT. The DELETE step works great, but the INSERT is not controllable at the moment and interacts poorly with the rest of the pipeline. Ideally there should be a way to cancel an INSERT SELECT mutation or wait until it finishes.)
The text was updated successfully, but these errors were encountered: