-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider removing the concept of terminating a query #3967
Comments
I think terminates are useful in the cases of long-running |
Thinking on this more, I don't think we need to explicitly terminate a query. Our CREATE TABLE AS SELECT style statements are akin to materialized views in the rdbs world. In the rdbs there is no concept of a persistent query exposed to the user. Instead, if you create a MV, when you drop the MV any 'process' in the background that is updating the MV is automatically stopped. The only thorn in our side is the
CREATE STREAM OUTPUT (...) WITH (...);
INSERT INTO OUTPUT SELECT * FROM SOURCE1 ...;
INSERT INTO OUTPUT SELECT * FROM SOURCE2 ...; Becomes: CREATE STREAM OUTPUT AS
SELECT * FROM SOURCE1 ...
UNION ALL
SELECT * FROM SOURCE2 ..
; Which once again brings us to a 1-2-1 relationship between persistent query and MV. So now when the user drops OUTPUT we can stop the persistent query, and we no longer need TERMINATE. |
An added benefit of In contrast the record ordering with |
+1 from me on removing @agavra raises a good point about -- pg_stat_activity tracks queries that are currently running
SELECT pg_terminate_backend(pid) FROM pg_stat_activity; |
Another possible use case for terminate would be to leave a table around for pull queries (I know we can't query tables directly yet, but surely we plan to at some point), but terminate the queries that populate it (e.g. it's like a snapshot table). |
Do other streaming systems not support some form of |
I was thinking about this and I think we can handle this with a query upgrade. We simply upgrade the source to have no query associated with it (but keep the DDL).
That's pretty trippy @vcrfxia - let me know if you come up with anything! |
With reference to the PR that introduced
TERMINATE ALL
syntax.We might look to remove the concept of terminating queries at all. We offer no way of restarting a terminated query, so why off a way to terminate?
If we choose to introduce a way to restart a query, then terminating actually means something. Restarting would be useful for re-kicking a failed query. However, there are probably better ways of handling failed queries. After all, a traditional db does not expose the state of the processing used to build a materialized view.
Removing
terminate
would address issues such as:The text was updated successfully, but these errors were encountered: