Hi naresh.chandra@copart.com

NOTE1: Yes, that's missing at the moment.
NOTE2: Thanks for the feedback. I forward this to our UI design.
NOTE3: you can double-click on the database name to set it as the active one.
About the slowness issue, what browser are you using?

Hi Duong,

I am using Mozilla Firefox.

Okay, there must be memory leak issues. To help me reproduce the issue, do you remember, how many worksheets are created in the query editor? Also how many session tabs?

Duong, Even I tried in the google chrome browser and single work sheet and single query tab also its not working.

If we try to stop the the query then we are getting the "Please reconnect" notification or lost connection or disconnection issue or mysql server has gone away error.

>> NOTE3: you can double-click on the database name to set it as the active one.
About the slowness issue, what browser are you using?
– But table objects should work as like auto intelligence.

About the slowness when switching between query tabs, do query tabs have data in the result section or they're just blank query tabs?
If there are large data in a query tab, when switching between query tab, it's expected to have such slowness because the result sets are stored in the browser's memory at the moment.

Yes but we are selecting only around 1000 rows only, but still its being slow. Can we change instead of browser to locally? Or can we think about to speed up the switching tabs any other way would be good.

Hi naresh.chandra@copart.com, we'll try to improve the slowness issue somehow. Anyway, do you have steps to reproduce the issue regarding the stop button?
e.g. what kind of query is being stopped?

Thanks for the update.

Its simple select query ["select * from table1;"] and the limit values is 10000.

Duong, We can send Kill query one time is enough to the destination DB, why because some times KILL command will take longer time, so we don't need to wait until the kill command finishes. So, we can just hit the kill query to backend db and automatically GUI should be available to run the query. I mean the run/stop button should be available after stopping the query.

naresh.chandra@copart.com It will be only possible if it sends `KILL thread_id` instead of `KILL QUERY thread_id` as it's now, which means the connection will be killed. https://mariadb.com/kb/en/kill/. However, killing the connection is not a trivial task. So if it takes time to kill the query, it's expected for the feature that we provide at the moment. We're going to add a loading indicator for stopping the query. e.g. When the stop button is clicked, it shows the loading indicator icon, so you won't mistakenly click again.

Duong, Yeah I got you but instead of waiting for stopping the query, we already sent the KILL command so no need to wait as the stopping process will take care by DB right so, instead of waiting GUI should be read for next query to run, so that we don't to wait for it like SQL yog, actually SQL yog is doing that only.

Okay, now I got the idea. The GUI will just abort the query request that is in a pending state after sending the KILL command.

However, with this approach, the GUI won't know when the query is actually stopped. So the GUI will show "Query canceled" in this case. I think that is expected

I don't think whether the query is stopped/killed, GUI will just send the KILL query that's it, immediately it should show query is stopped and ready for next query to be run mode. Any how, back end KILL command will be handled by DB itself, Once we stop the query, so we don't need to worry about the KILL query whether its executed/stopped/killed.

naresh.chandra@copart.com Hi Naresh, please create another feature request ticket for that matter.

Sure Duong,

Duong, Created a new request for the connection creation issue. Can you please take it forward for the next release, as its a very user friendly UI request.
Here is the ticket https://jira.mariadb.org/browse/MXS-4319