Hi Dan, all!
Dan Trainor wrote:
Thanks for the prompt reply, Augusto -
I completely understand what you're saying. To have anything such as a
real-time measurement to the exact number of tables would be an
incredible preformance degration, not to mention overhead and the like.
Right.
This is the conflict between fast operation (wanted by everybody) and
maintaining statistics (shared data = bottleneck).
I think I'm willing to accept the fact that while data is being sent to
the database server, I won't get an exact reading of database/table/row
size. This makes complete sense. However, what I am after, is how to
get the exact size of a database/table/row when NO connections are being
made.
What is the "exact size" you refer too?
Is it
a) the resources consumed on the disk (file size etc),
b) the data, index, and metadata stored (not including any gaps),
c) the "valid user data" which would be returned by SELECT statements?
Remember: In order to speed up further operations (inserts), a DBMS may
not shrink disk structures even if data get deleted (freeing up space).
So as long as the data are only growing, these three aspects may
correlate closely, but when updates and deletes start, this may change.
(Compare the use of heap space by "malloc()" and "free()" in C.)
In the MySQL case, different table handlers will show different
behaviour, further complicating the picture.
Say, if I started MySQL with no networking. This way, I could
positively ensure that no data modification would be taking place. Is
this possible?
For a), I recommend using the operating system means (Unix: "du").
For b) and c), I do not know the answer, but there may be ways.
Depending on the database size, getting any exact answer to b) or c) may
take longer than the "typical user" (a vague term, I know) is willing to
wait.
Regards,
Jörg
--
Joerg Bruehe, Senior Production Engineer
MySQL AB, www.mysql.com
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
