Roman Rokytskyy wrote:

>>As I see the things in developing world wide are going into very low
>>level of quality. More and more "developers" on forums are talking
>>about putting in blob fields almost everything (Word files, Huge
>>texts, Huge XMLs, etc). These things are compressed very well. So if
>>we have the option - "BLOB WITH ZLIB COMPRESSION" - these developers
>>will be very happy. That will be hit to performance - but if developer
>>wants it - let give it such thing.
>>
>>
>
>The only thing that is missing is a BLOB filter that peforms such
>compression shiped together with the server. As far as I understand,
>rest of the stuff is already there.
>
>However, I'm not sure if it makes sense to use zlib compression on the
>server - its CPU has other things to do. Just simply compress stuff on
>the client side, and job's done.
>
>
>

I originally had in mind using blob filters for compression, but that
really hasn't panned out. On the other hand, blob compression is a good
thing, and almost always useful (the exception is where it is already
compressed). It does take cycles to compress and decompress, but cycles
are increasing much faster than disk bandwidth.

The more I think about, the more I think that blobs should always be
stored compressed, but that compression/decompression be performed
primarily on the client side. The implication is that the plumbing
needs to be compression aware at least at the lower levels of the API.
If we're going to build in end to end compression, we pretty much need
to standardize on a single compression schema, and zlib is the obvious
candidate.

Now, having taken a position, can we have the opposing opinion from Dmitry?

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376