On 12 Jun 2019, at 03:08, Zingman, Jonathan wrote:

Yes, sys.queue(), sorry.

A couple of clarifications. The cookbook shows mclient, but we're using the API and we assume you can do the same thing from the API as well.

mclient uses MAPI.

Also, we use autogenerated queries that can be hundreds if not thousands of characters long. Matching in a case independent way would be very resource intensive.

Agreed, it’s only a quick workaround with limits, but it’s the only way I’m aware of with the existing features.

It's fairly clear from the documentation that MonetDB doesn't stop immediately in the middle of whatever it is doing, so that's understood. But cancelling queries has to be part of a robust database system.

Yes, it’s already a part of MonetDB. However, having a cancellation feature says nothing about how quickly it will take place. How I see this is, the query cancellation policy of MonetDB favours the performance of analytical queries, so, when it’s busy with a function, it doesn’t frequently stop to check if the query has been cancelled.

My model of how this might work is that the handle that’s returned when we issue a query could be used to associate with some data returned by sys.queue(), preferably tag or start time since those should be unique and fairly short. Then we stash then in some structure, and if a cancel request comes in, we do a much simpler search of the sys.queue() table that's guaranteed to work.

Yes, logically, this is the way to go. However, MAPI and sys.queue() were developed separately, they are in different levels in the software stack, and they are not aware of each other’s existence. So, when one wants to actually implement it, I just have no idea how much trouble it’ll be. Regards, Jennie

JONATHAN ZINGMAN | Manager – TrueCall Data | DIRECT: 510.809.0423 | CELL: 510.823.5638 | www.netscout.com

-----Original Message----- From: users-list On Behalf Of Martin Kersten Sent: Tuesday, June 11, 2019 1:56 PM To: users-list@monetdb.org Subject: Re: Cancel query

This message originated outside of NETSCOUT. Do not click links or open attachments unless you recognize the sender and know the content is safe.

On 11/06/2019 22:38, Ying (Jennie) Zhang wrote:

...

...

On 11 Jun 2019, at 00:58, Zingman, Jonathan wrote:

In the cookbook, you give a good way to find out the status of queries by using the sys.query() call,

Hai, Jonathan,

MonetDB doesn’t have a function called sys.query(). Did you mean sys.queue() instead?

...

which returns the list of queries tagged in various ways. Our question is whether there is any way to access, e.g., the tag value. In our application, we need to occasionally cancel queries from our UI. The UI has no direct knowledge of the query. While we might be able to find the query we want to cancel by comparing the query text, our automatically generated queries can be very long, and if there’s some internal reformatting by Monetdb, we might not get an exact match. So is there anything in the handle or elsewhere that we can use to identify the query we want to cancel?

Correct me if I’m wrong, but I’m not aware of a feature with which you can query the qtag of a query. Some code study will be needed to see if it’s feasible to add such feature, and how.

You can probably get away with string matching, since MonetDB doesn’t do much/any reformatting next to to-lowercase. Not sure how much text the “query” field of sys.queue() holds.

In addition, please be aware that i) sys.queue() is originally develop for debugging purpose… ii) the minimal cancellation entity is a function, i.e., when MonetDB is busy executing a very long running function, a cancellation will only take effect *after* that function has finished => then MonetDB won’t continue executing the next function.

Small correction here, with function we mean a MAL function call. So, if the system is executing a very time consuming join, it will *not* be interrupted, but rather at the end of it the query in which is rans is terminated.

...

Regards, Jennie

...

JONATHAN ZINGMAN Manager – TrueCall Data

2855 Telegraph Ave, Suite 200 Berkeley, CA, 94705-1169

DIRECT: 510.809.0423 CELL: 510.823.5638 http://www.netscout.com

_______________________________________________ users-list mailing list users-list@monetdb.org https://urldefense.proofpoint.com/v2/url?u=https-3A__www.monetdb.org_mailman_listinfo_users-2Dlist&d=DwIGaQ&c=Hlvprqonr5LuCN9TN65xNw&r=xNK1NJNBBpiLakjCb_Z9TJXbGF9L-j_RtJ5tXwCFwWY&m=Ezn_SsPU-bQGOePzCuzf_C29-ez6PakjdOl3Ry1Ihy0&s=PxXXp7rRyFasu_8I4E4hHdX4PTGWwz2pX1c8_v3zouU&e=

_______________________________________________ users-list mailing list users-list@monetdb.org https://urldefense.proofpoint.com/v2/url?u=https-3A__www.monetdb.org_mailman_listinfo_users-2Dlist&d=DwIGaQ&c=Hlvprqonr5LuCN9TN65xNw&r=xNK1NJNBBpiLakjCb_Z9TJXbGF9L-j_RtJ5tXwCFwWY&m=Ezn_SsPU-bQGOePzCuzf_C29-ez6PakjdOl3Ry1Ihy0&s=PxXXp7rRyFasu_8I4E4hHdX4PTGWwz2pX1c8_v3zouU&e=

_______________________________________________ users-list mailing list users-list@monetdb.org https://urldefense.proofpoint.com/v2/url?u=https-3A__www.monetdb.org_mailman_listinfo_users-2Dlist&d=DwIGaQ&c=Hlvprqonr5LuCN9TN65xNw&r=xNK1NJNBBpiLakjCb_Z9TJXbGF9L-j_RtJ5tXwCFwWY&m=Ezn_SsPU-bQGOePzCuzf_C29-ez6PakjdOl3Ry1Ihy0&s=PxXXp7rRyFasu_8I4E4hHdX4PTGWwz2pX1c8_v3zouU&e= _______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list