Query execution time reported incorrectly in 4.05

[sergius]

Minor bug in for SQLyog 4.05 (I glanced through the bugfix lists for versions 4.06 and .07 and didn't see this one); OS = Windows 2000.

When you execute a statement in SQLyog, the status line reports the (probably) correct execution time; for a multiple-statement script, it's the time for the last statement.

However, the message tab seems always to report “0 ms taken.”

[peterlaursen]

it seems to be the same with 4.06 and 4.07. I believe message “# ms taken” is a message sent from the server. And the message displayed probably is not the one relating to the SQL you just executed from from the SQL-pane.

Testing this issue I came across another bug (4.07).

to reproduce:

1) select a table in the Object Browser

2) click data tab

3) check “show all”

4) click messages tab

5) click data tab again.

… and the program starts working like mad without nothing happening. You'll have to stop the Sqlyog proces from tray or task manager.

[sergius]

Maybe it is coming from the server (in my case, MySQL 4.0.16), but the messages have everything to do with the statements that I executed:

(599 row(s) returned)

(0 ms taken)

[peterlaursen]

my server version (right at the moment) is 5.0.7 so it is no server-specific issue.

[sergius]

Apparently, the time reported is > 0 when there is a syntactical error in the statement, so maybe it's the time it takes the server to parse the statement or something like that…

Error Code : 1052

Column: 'gate_sweep_frequency' in where clause is ambiguous

(47 ms taken)

[Ritesh]

peterlaursen wrote on Jun 21 2005, 09:29 PM:

Testing this issue I came across another bug (4.07).

to reproduce:

1) select a table in the Object Browser

2) click data tab

3) check “show all”

4) click messages tab

5) click data tab again.

… and the program starts working like mad without nothing happening. You'll have to stop the Sqlyog proces from tray or task manager.

How many rows of data are there in the table?

[peterlaursen]

about 38000 😛

step 3) takes only a few seconds to complete

step 5 an eternity although it is basically the same!

Only difference is that message tab has been shown in between

I can try and let it run longer (I let it for about 10-15 minutes only) if you want me too.

When using OpenOfice Base Beta 2 as a client it is less than a second to load the whole table. And that is with either ODBC or JDBC -connector that should be slower than the C-API ….

It must be the heat in India … 😀

[Ritesh]

Are you connecting to a remote machine with tunneling on or it is a direct connection to your local server?

Quote:

It must be the heat in India …

It has started raining where we are located so the weather is pretty much OK 😀

[peterlaursen]

It's on localhost. Direct API-connect.

Try it yourself with one of the tables form my webserver (dump it to your local).

[Ritesh]

peterlaursen wrote on Jun 22 2005, 03:09 AM:

It's on localhost. Direct API-connect.

Try it yourself with one of the tables form my webserver (dump it to your local).

I just tried on 40000 rows and it seems to be OK. It takes time to get 40000 rows (which is expected) but it shows the data.

[Ritesh]

sergius wrote on Jun 21 2005, 07:41 PM:

Minor bug in for SQLyog 4.05 (I glanced through the bugfix lists for versions 4.06 and .07 and didn't see this one); OS = Windows 2000.

When you execute a statement in SQLyog, the status line reports the (probably)  correct execution time; for a multiple-statement script, it's the time for the last statement.

However, the message tab seems always to report “0 ms taken.”

This is not a bug.

The MESSAGE tab will show time taken to execute the query. The STATUS bar will show the time taken to fetch the data from the server to the client.

90% of the time MESSAGE tab will show 0ms taken as it does not take much time for MySQL to parse and execute the query.

[peterlaursen]

OK … I must accept that. But still don't understand why it is much faster first time than second time.

[sergius]

I'll try it again at some point, but I'm pretty sure it reported 0 ms taken even for very long queries (not necessarily with a lot of data to return, but the ones that took the server a long time to process).

[peterlaursen]

Quote:

… but the ones that took the server a long time to process

How can you tell if time was spent with the MySQL server or the Operating System/File System/Network Access ??

[sergius]

I can monitor the status of DB connections using the statement SHOW PROCESSLIST, for example.

[Author]

Posts