eikki Tuuri
> Cc: [EMAIL PROTECTED]
> Subject: Re: Altering InnoDB tables
>
>
> Heikki,
>
> I didn't config the log that big, but the buffer pool is using 1GB of
> memory, and yes, the UNIQUE index is definitely causing a lot of disk I/O!
>
> I will be very happy t
Heikki,
I didn't config the log that big, but the buffer pool is using 1GB of
memory, and yes, the UNIQUE index is definitely causing a lot of disk I/O!
I will be very happy to see your change, and thanks for (as usual) being
so quick to make changes to an already very welcome addition to MySQ
John,
did you configure innodb_buffer_pool_size and InnoDB log files big? Look at
the online manual on the recommended sizes.
If the table is very big, then UNIQUE secondary keys will cause a lot of
disk i/o, because a disk read is required to check the constraint for each
row, and the insert bu
Thus spake John Kemp on Mon, Jan 14, 2002 at 02:37:07PM -0500:
> 2) Then I tried mysqldumping the table structure, and changing MyISAM ->
> INNODB, dropped the table, and ran the mysqldump output back into the
> database. The INSERTS ran horribly slowly - something like 50,000
> inserts in 4 ho
I am also in the process of altering tables from MyISAM to INNODB. I
have one big problem - a very large table (> 5 million rows) with 5
indices/indexes on it, including a couple that are UNIQUE but with NULL
values allowed. Creating the last of these indices is taking an absurd
amount of time
I've recently converted from using MyISAM to InnoDB tables, and am
pleased with InnoDB so far. However, the inability to use 'ALTER TABLE'
with InnoDB tables is very problematic, as our software is still under
heavy development and our database schema changes frequently. I'm
working on a way to au
