[Ritesh]

peterlaursen wrote on Mar 3 2006, 02:14 PM:

@ritesh

I wrote this earlier

Are you PERFECTLY SURE, that you read and understood this.  You did not comment on it.  (Too) often that implies that you were not concentrated when you read it!

Now I ask you again: The solution that you have come up with, will it secure that a literal-keywords (ALL of them!) do not become a functional-keywords after multible reads and saves (and the other way around of course too)?

[post=”9004″]<{POST_SNAPBACK}>[/post]

I have read it completely. We have still not decided on the final structure of this feature. We will take it up completely after BETA 2.

Right now we are concentrating more on the auto-complete feature but let me ASSURE you, we will give 100% to each and every feature before releasing the FINAL.

[Ritesh]

Already assigned for BETA 2 or 3.

[Ritesh]

Exporting is already done in a different thread so that you don't get *inactive* GUI feeling while exporting data.

Do you mean exporting each tables in separate thread?

[Ritesh]

Can you give us more details about the crash?

Step by step procedure to reproduce the error would be very helpful.

[Ritesh]

SQLyog Max (under development) has been designed to support multiple-db starting with MySQL and PostGreSQL.

The first BETA (which is not available for PUBLIC anymore) supported both MySQL and PostgreSQL.

We are currently working on it but I am not sure whether support for non-MySQL db will be continued or not.

[Ritesh]

🙂

[Ritesh]

Permission problem fixed.

You should be able to make an attachment now.

[Ritesh]

We are doing some profiling for SHOW TABLES and INFORMATION_SCHEMA

If SHOW TABLES is really faster than SELECTing from INFORMATION_SCHEMA, we might give the user an option to continue using SHOW TABLES.

This is a funny situation created by MySQL AB. The deprecated syntax works faster compared to the bleeding edge INFORMATION_SCHEMA!

[Ritesh]

peterlaursen wrote on Feb 24 2006, 02:19 PM:

Those are created at connection:

/*[8:09:22 AM][ 94 ms]*/ show variables like '%character%'

/*[8:09:22 AM][ 62 ms]*/ Set character_set_connection=latin1

/*[8:09:22 AM][ 47 ms]*/ Set character_set_results=latin1

/*[8:09:22 AM][ 63 ms]*/ Set character_set_client=latin1

/*[8:09:22 AM][ 46 ms]*/ set sql_mode=''

This is executed when Object Browser is 'filled'

It should be *before Object Browser* is filled.

These are some connection specific queries. Not related to filling up of the Object Browser.

[Ritesh]

I had a talk with the MySQL developers on this issue and this is what they have to say.

Quote:

The above is a known issue with INFORMATION_SCHEMA.  It's especially harmful if there are many InnoDB tables, and if the server is using innodb-file-per-table option.  The reason is that the InnoDB statistics are being updated each time.

In fact, this slowdown is related to http://bugs.mysql.com/bug.php?id=13762 (SHOW CREATE TABLE slowdown with InnoD:cool:.

The bottom line is some optimization of INFORMATION_SCHEMA may be done in MySQL 5.1 and 5.2, but not planned in 5.0 as far as I know.

This is NOT AN SQLyog issue but rather MySQL's.

Navicat executes SHOW TABLES to get the table LIST but this method has been officially deprecated by MySQL AB for v5.x.

BTW, SQLyog will still execute SHOW TABLES for MySQL versions < 5.0.

[Ritesh]

Quote:

simply insert/update/drop a row to embedded database 'on the fly' when CREATE, ALTER, DROP and RENAME has been executed by mysql.

Indeed it does. On every CREATE/ALTER/DROP operation done through the SQLyog GUI will be handled separately and these operation does not require rebuilding the tag file.

@iliask problem is happening because on every key-press SQLyog tries to find a match for tool tip which requires it to issue a SELECT statement to Tags.db (which also accounts for 30-40% CPU usage) and slows down the typing experience.

We plan to put an option in BETA 2 where a user can disable TOOLTIP altogether. It will then show Autocomplete data only on TAB and . press.

[Ritesh]

If the data is not confidential, then can you send me a dump of the data?

I cannot correctly comment on the issue without looking at the data.

[Ritesh]

We are going to make numerous optimizations in the Auto-complete options before the FINAL release. It would not create ANY difference in the experience with or without autocomplete

[Ritesh]

peterlaursen wrote on Feb 26 2006, 08:26 AM:

But that would COMPLETELY disable auto-complete wouldn't it?

[post=”8935″]<{POST_SNAPBACK}>[/post]

No.

It will basically stop rebuilding on start up from second time. By default it will rebuild the tag files on start up which might not be necessary if you use SQLyog to make schema changes. However, disabling this feature would require you to manually start a rebuild if you make changes to the schema OUTSIDE SQLyog.

[Ritesh]

iliask wrote on Feb 24 2006, 11:51 AM:

Autocomplete seriously slows down writting of queries as it freezes the editor every other second to lookup for possible matches. I hope you'll speed up the search code before it's released to the public.

Also it would be nice if you could use the Data_length or Checksum of a table to make a decision whether to rebuild it's TAG files on the startup.

[post=”8908″]<{POST_SNAPBACK}>[/post]

Can you tell me your computer configuration?

Approximately, how many database/tables/columns are there in your MySQL host?

Rebuilding of the tag files are done in a separate thread so it should not effect your typing experience.

Also, you can disable building of tag files on each start up using Tools->Preferences

[Author]

Posts