Am 30.11.2011 07:02, schrieb Hal?sz S?ndor:
> 2011/11/29 23:19 +0100, Reindl Harald
> MY only luck is that i recognized this years ago after PLAYING
> with innodb and so i started with "innodb_file_per_table=1" from
> the begin with the first production database
>
> And are then
2011/11/29 23:19 +0100, Reindl Harald
MY only luck is that i recognized this years ago after PLAYING
with innodb and so i started with "innodb_file_per_table=1" from
the begin with the first production database
And are then the table-files in the directories with "frm", or in
Am 30.11.2011 03:13, schrieb Karen Abgarian:
> The concept is not difficult to explain. Most people do not expect a gas
> tank
> to shrink once the gas is consumed...right?
yes, but the hard-disk is the gas tank and the data are the gas
and yes, normally everybody would expect after deleting
>>>
Hi... and some more stuff inline.
>>
>> Well, I would not base my database design on luck and playing. There
>> should be good awareness
>> of what the features do and what would be the plan to deal with file
>> allocations should the database
>> grow, shrink or somerset
>
> if you
Am 30.11.2011 01:11, schrieb Karen Abgarian:
>> MY only luck is that i recognized this years ago after PLAYING
>> with innodb and so i started with "innodb_file_per_table=1" from
>> the begin with the first production database
>
> Well, I would not base my database design on luck and playing.
On Nov 29, 2011, at 11:50 AM, Claudio Nanni wrote:
>
> This is not to say that MySQL could not have more of the file management
> features. For example, the ability to add or remove datafiles on the fly and
> the
> ability to detach tablespaces as collections of tables.
>
> That's where MySQ
Hi... there is stuff inline there.
>> The logic behind this is probably that without innodb_file_per_table=1
>> and with several large ibdata files, the space IS freed up when one does
>> optimize table or drop table. The space is freed up inside the database
>> files and can be reused.
>
>
Am 29.11.2011 20:25, schrieb Karen Abgarian:
>
> On 29.11.2011, at 5:21, Reindl Harald wrote:
>> why is this dumb "innodb_file_per_table=0" default since MOST PEOPLE
>> have only troubles with it because they can not free space with
>> "optimize table" with no real benefits?
>
> The logic behind
>
>
> This is not to say that MySQL could not have more of the file management
> features. For example, the ability to add or remove datafiles on the fly
> and the
> ability to detach tablespaces as collections of tables.
That's where MySQL(read InnoDB) got stuck actually, it never introduced a
On 29.11.2011, at 5:21, Reindl Harald wrote:
>
> ibdata1 does NEVER get smaller, this is normal and a hughe problem
> in your case, only if you are using "innodb_file_per_table" which
> is NOT default would retire the space after drop tables
>
> why is this dumb "innodb_file_per_table=0" defaul
Am 29.11.2011 14:08, schrieb Luis Pugoy:
> Hello. I have the following problem.
>
> I was importing a large database to mysql using mysqldump. Unfortunately this
> filled up the whole disk, and
> mysqldump exited with an error that the table it is currently writing to is
> full. Checking df -h
11 matches
Mail list logo
