Another memory-issue

[peterlaursen]

1) I click object-browser and choose a big DB (my famous music-library). Click DATA-pane.

2) I click “show all” checkbox. Takes a few seconds to show all +38.000 rows (when no tunnelling)

3) Then I click another table (a small one) in object-browser. It now takes an eternity (+ 15 minutes) for SQLyog to switch the view to that other table that would normally show in a second. What is it doing? It should just drop the memory consumed by the old “show all” view. It should take less than a millisecond!

This is reproduced with and without tunnelling. I guess I remember that we have discussed some similar issues before. The answer given at that time I did not find acceptable, so please don't refer to that!

Sometimes I suspect that your developers just test with small “ad hoc” DB's and tables. But that can't be so – you probably have a Quality System implemented with well-documented test-suites built on “real life data” … 😎

[peterlaursen]

I just want to add that fixing this issue should not significantly delay release of neither 4.07 final or 4.1 (one big improvement does not need to await another!) – especially not 4.07 because I consider the “export-NULL” -bug in 4.06 to be critical.

[Ritesh]

This is a known issue. Its due to the data sturctures that we use internally. Optimizing this feature is already in our TO-DO list.

PS: Result-data does not suffer from this. Just execute select * from bigtable and then select * from smalltable.

[peterlaursen]

Quote:

Its due to the data sturctures that we use internally

Yes, of course!

As of now I have two options

1) Wait 20 minutes for SQLyog to display SMALLTABLE

2) Close down SQLyog and restart it. It can be done in less than 10 sec.

What do you think I do ?

Using RESULT-pane as you suggest could be a solution in situations where is is important not to lose HISTORY.

[Author]

Posts