I don't know if this is a bug, or I'm just missing something.

After running a batch of queries in SQLyog, I may get something like:

(1 row(s)affected)
(0 ms taken)

(141 row(s)affected)
(0 ms taken)

(141 row(s)affected)
(0 ms taken)

in the "Messages" window. Those were of course queries that did not take 0 ms each. I have no way of knowing how long each one took. Moreover, the status bar also doesn't show the time, and stays at "0 ms".

Is there something I'm missing, or is this a bug?

On another note, I would be really great if instead (or in addition) to the "X ms" in the status bar, it would say something like "X minutes, Y seconds, Z ms". For longer queries, the "ms" is useless, and I find myself using calc and counting digits

(Using SQLyog Enterprise 6.52, MySQL 5.1.24)

Thanks,
Shlomo

this FAQ explains what we are doing currently:
http://webyog.com/faq/content/8/147/en/how...light=execution

We display the execution time for individual statements, not for 'batches' ...

I see, so the measurements I was looking for are in the History tab... I understand it better, but I think I'm still missing something...

When executing single statements, the times in the messages and the times in the history are always the same, at least in the queries I've tried running.
What is the difference between the 2nd and the 3rd timestamp collections? Both of them are collected after the server reports a successful execution. The 2nd after the server returns a flag, and the 3rd after "execution of few lines of code".

And what do you think about my second comment?

If you are connecting to localhost then MESSAGES and HISTORY may be the same with very fast queries as there is no significant connection 'overhead'. First, second and third TIMESTAMP could be the same millisecond. Does this explain?


I tried executing a 'not-trivial' query to localhost (changing a table from MyIsam to InnoDB):


now

HISTORY displays
/*[13:21:27][ 374 ms]*/ alter table mytable engine = innodb ;"

and MESSAGES:
(515 row(s)affected)
(0 ms taken)


So here the MySQL server requiered almost 0.4 second to write data to the InnoDB tablespace, delete the MyIsam files and update whatever system tables and logs needed to be updated. HISTORY tells. MESSAGES tell that communication overhead between server and client is neglible with this connection.



As regards the Formatting request:
We have not had a team assembly since your first post but you can tell if you think it would be sufficient to do this formatting/calculation in the Status Bar?

Interesting. So in a case where communication between client and server is slow, "messages" should tell me how big the lag is.
I ran a heavy query on a remote server, to which I surely have more than 200ms lag.

History shows this:
/*[18:40:13][52978 ms]*/ alter table log engine = archive;

While messages says:

(37767 row(s)affected)
(0 ms taken)

Just like in your example. But in my case, communication is surely very slow. I get a ping lag of ~250ms to the remote site. Or is lag somehow deducted from this calculation?



Sure, it's good enough in the status bar... Although a configuration option that can do this for history/messages as well could be cool too. Anything above 60 seconds is very hard to grasp right away with just the milliseconds number, regardless of the location in the program.


IMHO, I would re-consider the UI logic here, so that it would be more straight-forward for new users.
Have 2 different measures, like now, only display them differently.

History should stay as it is - this is the same time the mysql command line client displays, basically.
Messages should display the same time like History, with an addition like "n ms overhead":

(37767 row(s)affected)
(0 ms taken, 5 ms network overhead)

Due to the fact it's plain text, it's easy to be fooled into thinking it's the same time as the mysql command line client. This is at least what I've thought so far - and I thought it was a bug since I see it at 0ms.
Status should display not the last query time, but the summary of the "history" times for all of the queries. I personally run batches a lot, and it is really useful to know how long they ran. Right now I need to sum the results from the History window...

Don't mean to be nitpicking, but it's just how it makes sense to me personally

Regards,
Shlomo