ian wrote:

>> It would be grossly incorrect to apply the Oracle page size rules to a
>> Firebird database.
>>
> Why? A page is a page, no matter what the database system.
>

Well, for one, Firebird 1.5 suffers slightly with a page size larger
than 8K because the probability of a long page scan in the index is
high and there's a CPU cost for expanding the index entries during
a scan. On the other hand, Firebird 2.0 restricts the size of an index
key to a fraction of the page size, so if you expect to index long
fields, a larger page size is appropriate. Firebird 2 also eliminates
the cost of expansion on pages larger than 2K, so larger page sizes
are a good idea for FB2.

Data and index compression pretty much cancel any possibility of
tuning a Firebird database to your record or index key sizes. If
your records are large and won't be reduced by run-length compression,
then make the page larger than the record. Blobs aren't compressed,
on the other hand, blobs are stored front to back, so if you have a
blob that's two and a quarter pages long, the first quarter page goes
on a data page and the rest goes on two completely full blob pages.

All databases are affected by the cost of reading and writing pages,
but the disk costs are hard to quantify without knowing what sort of
disk system you have. A RAM disk is quite different from a cheap IDE
disk and different yet from a striped RAID...



Regards,


Ann