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
Simon,
This limitation is only relevant for MyISAM tables, and your solution
(MERGE engine) also applies to MyISAM only. Please note however, that
MyISAM is deprecated for dbmail-2.1+ since we've stopped trying to
maintain referential integrety in the database-client (dbmail).
So you better
PJS Simon,
PJS This limitation is only relevant for MyISAM tables, and your solution
PJS (MERGE engine) also applies to MyISAM only. Please note however, that
PJS MyISAM is deprecated for dbmail-2.1+ since we've stopped trying to
PJS maintain referential integrety in the database-client (dbmail).
On 11/23/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
PJS Simon,
PJS This limitation is only relevant for MyISAM tables, and your solution
PJS (MERGE engine) also applies to MyISAM only. Please note however, that
PJS MyISAM is deprecated for dbmail-2.1+ since we've stopped trying to
PJS
On 11/23/05, Paul J Stevens [EMAIL PROTECTED] wrote:
This limitation is only relevant for MyISAM tables, and your solution
(MERGE engine) also applies to MyISAM only. Please note however, that
MyISAM is deprecated for dbmail-2.1+ since we've stopped trying to
maintain referential integrety in
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
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 AVG_ROW_LENGTH=nnn;
Got an
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 AVG_ROW_LENGTH=nnn;
Any
Simon:
This issue is version specific in its resolution.
Notwisthstanding some fairly large 'real' ones, I have built some
enormous dev mail databases with 'fake' users -- perl scripts pumping
'stuff' for days. I have had varying results depending on the MySQL
version, file system and the
Simon wrote:
Hi There,
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
Paul J Stevens wrote:
[EMAIL PROTECTED] wrote:
Importing that much data is slow. Just copy the files for backup then
alter. Check to see if the number of rows match.
Yes, dump and reload is slow, but it will most likely still be a lot
faster than an alter command.
OK.. so the process
Hi...
On 11/15/05, Dominic Amann [EMAIL PROTECTED] wrote:
ALTER TABLE tbl_name MAX_ROWS=10 AVG_ROW_LENGTH=nnn;
But before i do this, im just wondering if there is anyone out there
who has done this before, and it there was any issues/TFYPs in doing
so?
We did that almost right
Importing that much data is slow. Just copy the files for backup then
alter. Check to see if the number of rows match.
Simon wrote:
Hi...
On 11/15/05, Dominic Amann [EMAIL PROTECTED] wrote:
ALTER TABLE tbl_name MAX_ROWS=10 AVG_ROW_LENGTH=nnn;
But before i do this, im just
[EMAIL PROTECTED] wrote:
Importing that much data is slow. Just copy the files for backup then
alter. Check to see if the number of rows match.
Yes, dump and reload is slow, but it will most likely still be a lot
faster than an alter command.
--
Hi There,
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 AVG_ROW_LENGTH=nnn;
Simon wrote:
Hi There,
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
19 matches
Mail list logo
