> -----Original Message-----
> From: Firebird-Architect@yahoogroups.com
> [mailto:Firebird-Architect@yahoogroups.com] On Behalf Of Geoff Worboys
> Sent: 16. maj 2005 13:04
> To: Firebird-Architect@yahoogroups.com
> Subject: Re: [Firebird-Architect] Re: Record Encoding
>
> > But compressing compressed data will in many cases turn out bigger.
> > This is, as far as I have understood it, strictly opposed to the
> > intension which was to minimize the number of pages used to
> store the
> > data.
>
> With smart algorithms the size difference is generally not
> very significant. The primary cost comes with the time it
> takes to perform the compression. If there is no size
> benefit to offset the cost of processing then the time it
> takes is a total loss.
>
> If the time lost in trying to compress uncompressable data is
> significant then we will definitely need compression to be
> configurable. If the time lost is not significant then we
> can leave it on and ignore it - making it transparent which
> is the desireable goal.
>
> There is also a cost/benefit analysis to be done according to
> the size of the compressed data. If the data would fit into
> a normal blob storage block anyway, then there is no benefit
> in compression - except perhaps in transport to the client.
> In applications with mostly small blobs (I have many of
> those) then compression may not be desirable.

I totally agree. But I suspect that in most cases the database developer
knows whether th data of a specific blob column can be compressed or not. So
I see no reason why it shouldn't be up to the database developer to specify
whether the BLOB data of a column should be compressed or not.

Why use cock cycles (may that be many or few) detecting whether data can be
compressed or not each time data is stored if the database developer can
specify once and for all that it can't.


/Svend