>From: Jim Starkey <jas@...>
>>The other thing which would be nice would be the ability to specify

however

>>many database files, and have pages allocated round robin (or something)
>>across the files, rather than just allocation from the beginning. More
>>spindles, more bandwidth. Someone at Interbase must have been thinking
>>about this, although disk striping is probably just as good.
>
>A great deal of though went into the strategy. But hardware changes
>radically. Memory was $4000 / MB when I designed Interbase, and many
>"big" machines maxed out at 4 MB. Memory is now free for all practical
>purposes, disk are dirty cheap (but no faster), and cpu cycles are there
>to burn. The challenge for database designers is to take advantage
>of contempory hardware while preserving past investment.

Main memory is also much slower relative to CPU speed than it was.

Oh, and why is preserving the past investment important?

>The whole area needs a rethink.

Isn't that the point of this discussion?

>>These features aren't really on my priority list for Interbase at all, but
>>that is at least in part because the absence of these features means that

we

>>don't even consider Interbase for particular classes of problems.
>
>Placement control isn't a feature, it's an alibi. Asking for performance
>is perfectly reasonable. Telling a database designer how to do his/her
>job is self-defeating (at best).

If I could give a database the expected workload and performance
requirements, and let it figure out how to use the resources at hand, that
would be great. I don't see a way around some kind of workload
characterisation: Do you have a snazzy way of avoiding that?

Until that feature is delivered, I see decisions at the level of "these
tables will be heavily written, put them on volumes with fast writes, these
tables are big and aren't written often, put them on volumes with slow
writes" as a useful thing.

To extend your argument, aren't user created indexes a form of telling the
database designer how to do his job?

Jan.