Hi Sebastian,
It depends. In general, no. In some filesystems and operating
systems, it actually helps. I think you can base your decision on
whether it makes server administration easier for you.
Regards
Baron
Thanks
It seems there are no clear thresholds between I/O access, the number
Hei All,
I am new here (my name is Gábor Lénárt and I am from Hungary), and I
am also quite new to develop more complex applications using RDBMS,
MySQL in our case. I hope it's the right place to ask general
questions too. I have experience to create simple applications without
transaction
Hi
The purpose is really for auditing and constant performance analysis ? I
could save each query in my own user generated table. But thought maybe
best to use mysql's built in feature.
Neil
On Wed, May 27, 2009 at 5:22 PM, Baron Schwartz ba...@xaprb.com wrote:
Neil,
What is the purpose?
Scott Haneda wrote:
Unless you have very good reason to store binary data like an image in
your database, do not. It may work well for a time, but always be
prepared that your system will grow. If it grows a good deal relative
to your hardware, and users, and connections etc, you will always
Hello everyone ,
I wanted to make sure i didn't miss
something but after a few tests and doing some web/doc search i come to
the conclusion that we cannot restrain a user from dropping a database but
still being able to drop tables and etc ? I'm running
-Original Message-
From: Sebastien Moretti [mailto:sebastien.more...@unil.ch]
Sent: Thursday, May 28, 2009 2:38 AM
To: Baron Schwartz; mysql@lists.mysql.com
Subject: Re: innodb_file_per_table cost
Hi Sebastian,
It depends. In general, no. In some filesystems and operating
systems,
-Original Message-
From: mugisha moses [mailto:mossp...@gmail.com]
Sent: Thursday, May 28, 2009 12:11 AM
To: Arthur Fuller
Cc: mysql
Subject: Re: Can a MyISAM DB hold /everything/?
what if you had no issues of scaling, which would have less access
time, file system or database?
[JS] I
A significant gain you have with innodb_file_per_table is that of shrinking the
tablespaces.
You can do that with OPTIMIZE TABLE innodb-tbl;
You ibdata1 file should only contain metadata and some transaction logging info.
If your ibdata1 is gigantic, you have to do the following to shrink it:
We have found a major bug in MySQL that causes MySQL to silently
truncate date in LONGTEXT fields when innodb is used and MySQL fails to
convert characters in a string to the configured charset of the column.
This results in mangled/destroyed data. Since MySQL is kind enough to
not report any
[JS] I strongly suspect that MySQL, like any other random access, variable
record length scheme, would find it easier to manage the internal layout of
separate files. The rows would tend more to be of similar sizes, leading to
less obnoxious fragmentation, and the files themselves would be
The times I have heard, this is just a test, hack it together, or
this will never see significant load are more than I care to count.
Worse, the times that those statements ended up being false, and a
rigged and hacked demo code base become production has taught me to
treat all work as
A bit of a confusing set of replies was in the previous thread...
Doing my best to answer the issue at hand, please reference past posts
if my reply is not clear...
On May 28, 2009, at 6:04 AM, PJ wrote:
Could you clarify/expand on this a bit - I am setting up a site
where I
expect to
12 matches
Mail list logo
