>> Do you have any reason to believe that there is significant
>> overhead when compressing a pre-compressed object?

> That needs checking, but zipping up a few 200k JPG and a few
> 10Mb TIFF files - I can't see that there is any gain - in
> fact two of the TIFF's came out bigger - just - in 12 and 14
> seconds ;)

I think Jim's point was not whether there was any gain, but
whether there was any loss. eg: If the cost of compression is
small enough then there would be no problem with doing it even
when there is no benefit.

To this end I did a really quick and nasty test.

Copying 220Mb of JPG photos to new files took me about 45
seconds. Zipping the same 220Mb of files into a single zip
took 60seconds. The resulting zip file was around 215 Mb.

So approximately a 33% cost in time for a 1% gain in space.

This is of course way too fuzzy a measurement to be taken
seriously. Lots of GUI stuff in the way of both tests along
with caching issues and so on. OTOH there is obviously a
cost involved. Real testing is required, with investigation
of various options to avoid the pitfalls.

> Still I have no reason yet to be storing them *IN* Firebird.
> I'll just stick to storing the file name for now and wait
> for other improvements ;)

I already use a specialised photo database product, and have
often thought that I would like to do it better as a FB
database (given time etc). I also happen to have written a
dog pedigree database that stores photos - using Firebird.

If FB were to come out with a high cost always on compression
then these are two applications it would not be used on. If
compression is effectively "no cost" or can be disabled, then
it remains an option.

Both products are the sorts of things likely to be used on home
computers, which are often not latest and greatest hardware, so
the cost in both memory and CPU is highly relevant.


I think I am amongst the accused - of trying to denigrate a
"new" idea. It is an interesting idea, it is just that I am
really not sure it should be a priority. I do see compression
and encryption very similarly in this respect. Both are
interesting and often discussed aspects of database management
systems. Both have other solutions with proven track-records.

The advantages of introducing such features internally into FB
are less clear. There is no doubt that there are costs; CPU
cycles, memory and code complexity. But are the advantages
(being able to specialise the solutions to how the dbms works)
enough to make the costs worthwhile? Maybe, without LOTS of
study and testing there is no way to make an assessment.

This is why I have emphasised the need to make it optional.
With optional compression we can get lots of people to test
the results in a variety of real applications. If it does not
work well in a general sense then it can be turned off, if it
does work well then we have all learnt from the experience in
a way that has not hurt too much.

--
Geoff Worboys
Telesis Computing