plinehan wrote:

>
> Hmmm.... my question would then be, exactly how many Firebird
> servers run on that sort of hardware? I would respectfully
> suggest very few - RAID arrays for some, maybe.
>

That may be correct, but the applications that need that level
of performance tend to be the ones that can afford hardware.

>
>
> Well, part of my question was about whether the code was there
> in the original IB6.0 release?

No. Often placement control is used to avoid disk head contention
when doing indexed reads. Typical database access strategies
require reading first from the index, then the data area to retrieve
a record, then back to the index to identify the next target record,
then back to the data area again. Putting indexes on different disks
reduces that head contention. Firebird (and InterBase) handle indexed
access differently, first identifying all the qualifying index entries
then accessing the data.

> As I said, I have memories of
> it being mentioned - it would be a "nice to have" and it
> wouldn't just be performance - selective backups for example?
>

The Interbase and Firebird philosophy says that a database is
a group of related tables. That makes selective restore a
non-issue. No one could work with a database that's half
Thursday and half last Saturday.

> Read only tablespaces?

Unh, access control? What's the benefit of read only tablespaces?

> It could be an option for advanced
> users while maintaining the current configuration as the
> default - it's just an idea that struck me. Performance will
> not be an issue for me with my "briefcase" type app.

Life is complicated enough without adding features for advanced
users that don't have clear utility and performance benefits.


Cheers,

Ann