Subject Re: Record Encoding
Author adem
From: geoff@... (Geoff Worboys)
>
>BUT a relatively small technological break through could bring
>SSDs back into the limelight quite quickly.

True, but how does this alter the basic assumptions to Firebird?

Already, disk size is assumed to be practically infinity. We are
concerned with I/O speed which SSDs will not drastically alter.

Unless I see something like InfiniBand applied to SSDs, I will
consider SSDs to be hardisks with a different internal media
and faster seek times.

>The moral of the story is that development really needs to be
>concentrated in the here and now. Sure, we keep an eye on what
>may be coming and try to enable our developments to take
>advantage in such areas, but to base success on what may
>appear is a risky business.

AFAIS, for our purposes, here and now is:
X86, X86_64 CPUs, dual and/or dual-core,
say, upto 16 GB RAM
10BaseT, 100BaseT, 1000BaseT,
ATA133, SATA150, SCSI320
RAIDx (inc. RAID5/RAID50/RAID6)

For immediate tomorrow:
SATA300, SANs
10GbE (10 Gb Ethernet)
ToE (TCP Offloading Engine)
Compression and Encryption Engines

IOW, from what I see, only the storage and network will see
any major improvement. But, I do agree that it is a fool's
game to predict anything into the future.

>I believe that IB/FB has had the right approach so far. Leave
>such things as compression and encryption to external services.
>We already have operating systems services for on-the-fly
>encryption and compression. Similarly there are network
>services to fulfill the same requirements. (Note that
>encryption also provides compression.) The real advantage of
>these external services include:
>
> - they are user configurable; can be turned on/off as per
> the needs of the particular installation, with users
> choosing an implementation that best suits them.
>
> - they work for other things besides FB; so users can
> configure ONE service and have the advantage across
> all their applications.
>
>So why does FB need to repeat what is already available in
>tested, stable and efficient implementations?

Thanks. This is gist of what I have been trying to say :-)

Cheers,
Adem