Paul J Stevens wrote: > [EMAIL PROTECTED] wrote: > >> I can't make "OPTIMIZE TABLE dbmail_messageblks" because of more >> than 55Gb data in it's table. > > I would guess that is a generic problem for people running volatile > sql databases. Doesn postgres' autovacuum solve this?
I'd like to answer but I don't understand the MySQL (4.1) docs. "Deleted records are maintained in a linked list and subsequent INSERT operations reuse old record positions. You can use OPTIMIZE TABLE to reclaim the unused space and to defragment the data file. In most setups, you need not run OPTIMIZE TABLE at all." I don't see if the OPTIMIZE is necessary for MySQL to reclaim space. Postgres' (auto)vacuum does this without locking the table. VACUUM FULL additionally compacts/defragments blocks, this needs an exclusive lock but in my experience it is not necessary at all. >> In my opinion it can be solved by a little bit another table >> structure. For an example we can make new database for each user >> and than make table space for him from create-mysql-innodb file. > > You can do that already. Run dbmail-2.1 in cli mode though a tunnel: > > ssh [EMAIL PROTECTED] 'dbmail-imapd -n -f ~/dbmail.conf' > > that way you can give each user his/her own dbmail database, use > different databases per user, or per group of users, use different > sql drivers, different auth drivers, etc.... I'd be interested in the performance difference of one big database versus several hundred/thousand small ones (it that works at all) ... Greetings, Thomas
