Hans Kristian Rosbach wrote: >>> I have a few questions / suggestions for 2.0 that might need to be >>> implemented to schema before 2.0 is released. >>> >>> 1. Support for compressed message body >> >> I believe that postgresql already compresses text fields that exceed >> a certain size, so think is already being handled at the DB level. >> Granted the compression PG uses is designed for speed more than size. >> >> http://www.postgresql.org/docs/7.4/interactive/datatype-character.html > > Interesting.. Very little documentation on that tho.. > > But from what I have managed to dig up, I have found that you need to > create the database with this parameter: "storage=extended" (dafault > is > plain) for the compression and the moving of the object out of the > table. No you don't. A TOAST table is created by default.
It will compress most tuples without any intervention at all. > > 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. > -Compression ratio is probably lower It's a Zip type algorithm. It works well. > -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. > > 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? Larry Rosenman (who reads ALL the PGSQL lists, and has contributed code to them before). -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
