Igor, I think we shouldn't mix management and select syntax. Potentially it can be dangerous. e.g. your example you don't know set of queries which will be cancelled. Also I have not seen such approach in other databases.
Yes, the syntax should work from SQL API also. вт, 13 нояб. 2018 г. в 14:20, Igor Sapego <isap...@apache.org>: > Yuriy, > > Would not it be more convenient fro user to write a request in a free > form, like > KILL QUERY WHERE ... > > For example, > KILL QUERY WHERE duration > 15000 > > Or is it going to be too hard to implement? > > Also, is this syntax going to work only from thin clients, or if it just > designed for them, but will also be usable from basic SQL API? > > Best Regards, > Igor > > > On Tue, Nov 13, 2018 at 12:15 PM Юрий <jury.gerzhedow...@gmail.com> wrote: > > > Igniters, > > > > Some comments for my original email's. > > > > The proposal related to part of IEP-29 > > < > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-29%3A+SQL+management+and+monitoring > > > > > . > > > > What purpose are we pursuing of the proposal? > > We want to be able check which queries running right now through thin > > clients. Get some information related to the queries and be able to > cancel > > a query if it required for some reasons. > > So, we need interface to get a running queries. For the goal we propose > > running_queries system view. The view contains unique query identifier > > which need to pass to kill query command to cancel the query. > > > > What do you think about fields of the running queries view? May be some > > useful fields we could easy add to the view. > > > > Also let's discuss syntax of cancellation of query. I propose to use > MySQL > > like syntax as easy to understand and shorter then Oracle and Postgres > > syntax ( detailed information in IEP-29 > > < > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-29%3A+SQL+management+and+monitoring > > > > > ). > > > > > > > > пн, 12 нояб. 2018 г. в 19:28, Юрий <jury.gerzhedow...@gmail.com>: > > > > > Igniters, > > > > > > Below is a proposed design for thin client SQL management and > monitoring > > > to cancel a queries. > > > > > > 1) Ignite expose system SQL view with name *running_queries* > > > proposed columns: *node_id, query_id, sql, schema_name, connection_id, > > > duration*. > > > > > > node_id - initial node of request > > > query_id - unique id of query on node > > > sql - text of query > > > schema name - name of sql schema > > > connection_id - id of client connection from > > ClientListenerConnectionContext > > > class > > > duration - duration in millisecond from start of query > > > > > > > > > Ignite will gather info about running queries from each of nodes and > > > collect it during user query. We already have most of the information > at > > GridRunningQueryInfo > > > on each of nodes. > > > > > > Instead of duration we can use start_time, but I think duration will be > > > simple to use due to it not depend on a timezone. > > > > > > > > > 2) Propose to use following syntax to kill a running query: > > > > > > *KILL QUERY node_Id query_id* > > > > > > > > > Both parameters node_id and query_id can be get through running_queries > > > system view. > > > > > > When a node receive such request it can be run locally in case node > have > > > given node_id or send message to node with given id. Because node have > > > information about local running queries then can cancel it - it already > > > implemented in GridReduceQueryExecutor.cancelQueries(qryId) method. > > > > > > Comments are welcome. > > > -- > > > Живи с улыбкой! :D > > > > > > > > > -- > > Живи с улыбкой! :D > > > -- Живи с улыбкой! :D
