From: Ann Harrison <harrison@...>

>Second, what can (should?) be done to distribute load across
>disks?

This reminds me of something else I was going to ask ...

What does the internal Interbase abstraction look like between tables,
blobs, etc., and the underlying database file itself? There must be a bunch
of meta data applicable to the database file(s), like free pages, and
presumably some kind of object directory ...

Do higher level objects have knowledge about the underlying structure of the
database file? For example, in b-tree leaf nodes are pointers to table
pages stored as database file relative page numbers or table relative page
numbers? Are pointers between interior node pages relative to the file, or
the index? Etc.

When table (or index, or whatever) page becomes empty, is it released back
to the underlying database file, or is it retained by the object for future
use? Does page allocation to objects happen by extent or a page at a time?

If the abstraction is clean, and addresses are relative to the object in
question, the various objects could be put directly into filesystem files,
with administrator control over object placement. This is more useful than
just striping disks.

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.

Implementing full scale table spaces probably doesn't fit with the Interbase
code at all, and would (I guess) mean replacing the entire database file
abstraction with something much more complex.

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.

>(asking for trouble, she is.)

You called? :-)

Jan.