Simon wrote:
Good point. Im starting to look into moving to innodb tables, but will
save the actual upgrade until a server upgrade in Jan/Feb of next year
:) . Any good references to start here?
Read section 15.7.2 in the mysql manual.
set unique_checks=0;
alter table dbmail_users
Simon wrote:
It looks like we have reached the Max_data_length for the
dbmail_messageblks table, this is currently 4294967295 (which is 4GB
im gussing - which is about right). From the mysql docs, this can be
easliery solved by running:
ALTER TABLE tbl_name MAX_ROWS=10
S ) TYPE=MERGE UNION(dbmail_messageblks_part1, dbmail_messageblks_part2)
S INSERT_METHOD=LAST;
It's rather interesting decision. I wonder is it real to build
something like an array of merged dbmail_messageblks_partX tables?
In previous maillists I have asked about big dbmail_messageblks
You have fixed a short term problem but forgot about long term
consequences.
Email system is a delete/insert/update/select heavy system, if you have
lots of users. Going with innodb you get concurrent reads + writes. I
can do most of the dbmail-util cleanup functions without having to lock
On 11/24/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
You have fixed a short term problem but forgot about long term
consequences.
Email system is a delete/insert/update/select heavy system, if you have
lots of users. Going with innodb you get concurrent reads + writes. I
can do most of
