I would like to know whether you will be adding a feature (another bullot on MONYog Monitor's left frame) for the MONYog where you can display teh following three statistics.
Data Size: (on the disk): Sum of all *.MYD files for the current database and display in Mega Bytes
Index Size: (on the disk): Sum of all *.MYI files for the current database and display in Mega Bytes
Total Size: [Data Size + Index Size + Otthers (sum of all *.frm files)] in MB.
Or You can add this feature as part of SQLYog. After connecting to a server, when the user right click's on a particular database icon, there should be an entry to view "Detailed properties". Under that you should have "DATABASE SIZE" as one of the selection options, and when user selects that you should display the current size information.
-joe6P
Full Version: Showin Database Size
What your are requesting is a engine specific parameter. I think we will concentrate on parameters and metrics that are not engine specific. Basically because at this moment (with the introduction of the Falcon engine and 3rd party engines) it is very uncertain what engines would 'normally' would be used as storage engine(s) with MySQL (MyIsam, InnoDB, Falcon, Solid, pbxt) in the future.
At least
* authentication
* notifications and alerts
* trend analysis
.. should be introduced first in my opinion.
For those storage engines (Innodb, Solid) that use a 'table space' not controlled by the file system but by the code of the storage engine itself it is not easy to tell the size of individual tables and databases. They simply are (normally) not individual files.
Why do you need this feature?
At least
* authentication
* notifications and alerts
* trend analysis
.. should be introduced first in my opinion.
For those storage engines (Innodb, Solid) that use a 'table space' not controlled by the file system but by the code of the storage engine itself it is not easy to tell the size of individual tables and databases. They simply are (normally) not individual files.
Why do you need this feature?
Peter,
Thanks for the clarification. The idea is to get a sense of database size. I had MyISAM in mind when I posted earlier. It becomes tedious if you have 10s, if not 100s, of tables and you have to manually compute the size. Will trend analysis have anything to do with size? I will write a small perl script to do the job for me.
-joe6P
Thanks for the clarification. The idea is to get a sense of database size. I had MyISAM in mind when I posted earlier. It becomes tedious if you have 10s, if not 100s, of tables and you have to manually compute the size. Will trend analysis have anything to do with size? I will write a small perl script to do the job for me.
-joe6P
QUOTE (peterlaursen @ May 30 2007, 04:26 PM) 
What your are requesting is a engine specific parameter. I think we will concentrate on parameters and metrics that are not engine specific. Basically because at this moment (with the introduction of the Falcon engine and 3rd party engines) it is very uncertain what engines would 'normally' would be used as storage engine(s) with MySQL (MyIsam, InnoDB, Falcon, Solid, pbxt) in the future.
At least
* authentication
* notifications and alerts
* trend analysis
.. should be introduced first in my opinion.
For those storage engines (Innodb, Solid) that use a 'table space' not controlled by the file system but by the code of the storage engine itself it is not easy to tell the size of individual tables and databases. They simply are (normally) not individual files.
Why do you need this feature?
At least
* authentication
* notifications and alerts
* trend analysis
.. should be introduced first in my opinion.
For those storage engines (Innodb, Solid) that use a 'table space' not controlled by the file system but by the code of the storage engine itself it is not easy to tell the size of individual tables and databases. They simply are (normally) not individual files.
Why do you need this feature?
Peter,
Thanks for the clarification. The idea is to get a sense of database size. I had MyISAM in mind when I posted earlier. It becomes tedious if you have 10s, if not 100s, of tables and you have to manually compute the size. Will trend analysis have anything to do with size? I will write a small perl script to do the job for me.
-joe6P
Thanks for the clarification. The idea is to get a sense of database size. I had MyISAM in mind when I posted earlier. It becomes tedious if you have 10s, if not 100s, of tables and you have to manually compute the size. Will trend analysis have anything to do with size? I will write a small perl script to do the job for me.
-joe6P
QUOTE (peterlaursen @ May 30 2007, 04:26 PM)
What your are requesting is a engine specific parameter. I think we will concentrate on parameters and metrics that are not engine specific. Basically because at this moment (with the introduction of the Falcon engine and 3rd party engines) it is very uncertain what engines would 'normally' would be used as storage engine(s) with MySQL (MyIsam, InnoDB, Falcon, Solid, pbxt) in the future.
At least
* authentication
* notifications and alerts
* trend analysis
.. should be introduced first in my opinion.
For those storage engines (Innodb, Solid) that use a 'table space' not controlled by the file system but by the code of the storage engine itself it is not easy to tell the size of individual tables and databases. They simply are (normally) not individual files.
Why do you need this feature?
At least
* authentication
* notifications and alerts
* trend analysis
.. should be introduced first in my opinion.
For those storage engines (Innodb, Solid) that use a 'table space' not controlled by the file system but by the code of the storage engine itself it is not easy to tell the size of individual tables and databases. They simply are (normally) not individual files.
Why do you need this feature?
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.