> No you don't. A TOAST table is created by default. Yeah, I figured that after a while
> It will compress most tuples without any intervention at all. Nice. Any idea what defines a "large enough" string? > > So this is not really a good solution I think, since it has the > > following disadvantages: > > -Uses a less used storage tecnique, possibility of errors occur -Very > > little documented (As far as I could tell) -It does not compress/move > > all data, only that of a certain size And what is that size? 100K? > > 10M? It only says max 1GB. > It has worked very well (I had an app where I was storing PDF's and other > things > Without a problem. I stand corrected. At first it seemed like a nearly unused option, but it is indeed default behaviour. > > -Compression ratio is probably lower > It's a Zip type algorithm. It works well. Ok, nice. > > -CPU load will be on the dataase server, this is a BAD thing in a > > big system with several other servers running the smtp and pop3 > > daemons. > It only decompresses when it needs to. Good. > > Thus I still vote for implementation of the blobs and is_compressed > > flag. Are there any negative sides to this approach? > Why add more overhead to your app, when the server already handles it? Well, if we compare with a gmail-like setup of free mail accounts and huge space for everyone. This is just a mock up, but might be an actual implementation: 1 Database server with 15x300GB disks = ~3TB for the database Dual Opteron cpus, 4GB ram with 1gb per channel. 3 Incoming relays. Athlon64, 1GB ram each. Almost no diskspace. These run antivirus, spam, ++ 2 POP3 servers. Athlon64, 2GB ram each. Almost no diskspace. 2 Webmail servers. Athlon64, 2GB ram each. Then add 100.000 users. Do you see why I regard the database server as the bottleneck? The only good alternative I can see is the upcoming Mysql 4.1 w/clustering capabilities. Where you can for example have 5 servers, 1 Master (not storage), 2 of them share the whole dataset + mirrors of those two. The database portion is the least easy part of the dbmail setup to scale up to BIG loads. Smtp, pop3, imap and webmail are all easily scalable just by adding more computers. Thus moving the compression off the database server would let us scale even higher. But right now I would be happy enough if we just moved the headers out into a separate table so that it can have a different storage type than that of the rest of the mailbody. This would allow scaling better. I'd also like an acl setting for allowing only specific users the right to use imap *hint*. -HK
