Jan,

> I see your point. However, since FB is able to use >2GB files (by
> utilising 64bit 'addresses'), it being a 32bit app does not

necessarily

> mean it is unable to address anything beyond a 32bit address. If

it can

> do it on disc, it can do it in memory I would say.
>

I think you confused DISC IO addressing and RAM address access
ranges.

FB has not any sort file size paramater if i know correctly, and
not required.

These config paramaters and sort in RAM, written and added by
D.Yemanov a few years ago.

If it can do it on disc it may not be do it memory i would say.
Physical RAM capacity < Virtual RAM capacity < DISC capacity.
Physical RAM limit are 36 bits on EM64T systems, 40 bits on AMD64
systems.
So, an intel can address max 64GB, AMD can 1TB.
Your OS may be 64 bits but, FB is a 32 bits system at now.

If you have mass reads from DBfile,
then leave the caching operation to the OS, not to FB.

> I am using a 3ware 3w7000 series SATA RAID controller. I'm running
> Firebird 1.5.1 (Debian Sarge package).

I have no idea about your HW but,
alot of main boards has two independent SATA controller chips.
so, if you made an 4 DISC RAID system this mean, they are controlled
by a software at OS level.

> The DB design is of course important. However, in this case the

amount

> of records to read can be quite large for most queries. The DB is
> already fully optimized, its just dealing with quite a lot of

data...

Ok, i understand. i have such problems too, but i am not luckily as
you because my Firebirds runs on fossil computers.

>
> I am looking for a way to make best use of the available RAM

(8GB).

> Either I can do that by using FB's built-in mechanisms such as the
> different caches. This would be my ideal situation. I could also

put my

> hopes in the Linux caches...

Linux caches may helps more here.

>
> Another approach would be to split the DB in two parts, and

storing the

> part that is searched most on a RAM disc. This will create cross
> references between the two DBs. While it would be interesting to

sort

> out, I much prefer to keep focessed on the application.

DB splitting increases complexity i think. buying an extra 8GB will
be more cheap for you. ( so, OS can cached your DBfile fully)

>
> Any more thoughts are very welcome!
>
> cheers,
> Jan
>

Regards.
Ali