> >>I'm losing my enthusiasm for compressed blobs. I'm not convinced the
> >>big win is there.
> >>
> >>
> >I agree with you here.
> >
> >Simple analysis of the comparisons for compression speeds, etc for

different

> >algorithms found from google seem to indicate that compressing on

reasonably

> >modern machines is around the 1-3 MB/sec mark. On tests that I have run

with

> >a large disk seek component on a standard serial ATA disk reveal that the
> >disk is capable of about 4MB/s sustained transfer rate. (Of course,

linear

> >reads off the disk are round about the 55MB/s mark, but that doesn't tell
> >you anything useful for real life usage patterns).
> >
> >
> >
> For blob compression to be worth implementing, the decompression cost
> should be reasonable close to the CPU cycles to read the number of
> blocks equivalent to the pages not written. The cost of kicking off an
> I/O operation is reasonably high -- cross the protection ring, probe
> addresses, queue the operation, put the process/thread to sleep, thread
> or context switch, service an interrupt, mark the thread runnable, and
> context or thread switch back. Ifthe CPU time is equivalent to the
> elapsed time, (as appears to be the case), we're dead.
>
> I think the answer is either more appropriate compression schemes or
> forgoing blob compression.

How about the client decompression?

With regards,

Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, Oracle & MS SQL
Server
Upscene Productions
http://www.upscene.com