Jason Dodson wrote:

>Using a plugin architecture allows sys admins to say, sacrifice
>"performance" for better compression if they bare that need.
>
>
>

Performance is a delicate tradeoff between memory usage, cpu usage, and
disk operations. A less efficient compression algorithm may be faster
but result in more page reads/writes, so system performance is slower.
As designers, we should tune for aggregate system throughput, which
require a careful cost/benefit analysis. A DBA isn't going to have the
tools, the knowledge, or the time to do the analysis, and if he did, he
would presumably come to the same conclusion as we did. On the other
hand, there are always going to be dufuses who don't believe in
trade-offs who will argue that algorith a is better because it is
requires few cpu cycles or b is better because it does better
compression. This is how systems get a reputation for hard to use.

There will also be two schools of thought. One argues that one size
fits all is intrinsically bad. The other argues that doing it right is
better than giving poor users a choice of bad alternatives. You might
note that Firebird a) unlike other databases, has no index tuning
parameters, and b) Firebird indexes perform better than databases give
expose index tuning parameters. See also placement control.

>It also allows for better and/or more efficient compression methods to
>be used as they come available. Certainly what we know as "good" now
>wont forever be the case.
>
>

We need to ability to phase in new algorithms, but this doesn't dictate
that we make it a user option.

>I also think a blunder comes along when you address the compression to
>be done on the client side... if the compression mechanism changes
>between versions for whatever reason, you will lose backward compatibility.
>
>

The compression code is part of the client library and, like other
things, is negotiated at connection time. If the client doesn't have
support for the engine algorithm, the data sent uncompressed for server
to compress.

>Maybe a better idea would be to have transmission compression and
>storage compression. The transmission compression can be negotiated on
>connection (useful for the poor client on a 486, where compression could
>hurt more then help), and storage compression be whatever the server
>feels appropriate.
>
>

That's the worst of all alternatives. Besides, the 486 belongs either
in the attic or holding a door open. We should make our tradeoffs for
contemporary hardware, particularly when a replacement your 486 can be
had for $300 (shipping included).


--

Jim Starkey
Netfrastructure, Inc.
978 526-1376