Jim Starkey wrote:

> Here are the major points made so far:
>
> 1. Blob compression is a performance optimization that trades CPU
> cycles to decompress to reduce the number of page reads.

Agreed - if not at the expense of fast access to data already processed
for direct seeks.

> 2. Blob compression should be automatic and invisible to users

No reason it can't be invisibly on or off

> 3. Blob compression is problematic with blob seek, and an acceptable
> compromise must be found, though the compromise may require a
> per-blob compromise

Such as accessing parts of any multi part image file which has
pre-compressed elements - thumbnail, data, and raw image - It's not just
text that can be directly accessed. Although it makes sense to pull
these files apart before storage anyway and store each part in a more
accessible format.

> 4. Client side compression and decompression has the double benefit
> of reducing the server CPU load while reducing the number of byte
> and packets transmitted over the wire

Any compression of what is on the wire will help, but it does not - as
you have indicated - have to be the compression that is used in storage.
A simple compression of all the data in a message, with a compressed
blob as a separate message? Server just uncompresses the bits it needs
to and shoves the rest straight onto disk?

> 5. Even with client side compression and decompression, the engine
> must be able to decompress blobs to execute operators and UDFs.

I still think that we need some way of differentiating between 'text'
blobs and 'binary' blobs? So that a 'LIKE' applied to a JPEG gives an error?

> 6. Provision must be made for future rolling upgrade to better
> compression schemes

That is taken as read ;)

--
Lester Caine
-----------------------------
L.S.Caine Electronic Services