At 09:06 AM 3/26/00 +1000, you wrote:

>From: "Jan Mikkelsen" <janm@...>
>
>From: Ann Harrison <harrison@...>
>
>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.
>

Interbase records are generally identified by a record number. To
access a record, the record number is decomposed first to a relative
pointer page number (table specific), and a slot on the pointer page
giving the number of the data page. Another decomposition gives the
line number on the data page. Each data page has a line index giving
the offset and length of the record fragment. On good days, the
record is complete. On other days, the record may have been modifier
so it no longer fits on the primary database, in which case it points
to another fragment. It also has the id of the transaction that
created it and possible a pointer to an old version.

Interbase tries to store blobs on the same page as the parent record.
If this is not possible, it stores it elsewhere. Big blobs are stored
in pages in a table's page space, but are marked as boring so a
sequential scan can ignore them as boring.

>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?
>

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.
>

Place control is dumb. See previous flame on the subject.

>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.

The whole area needs a rethink.

>
>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).

>>(asking for trouble, she is.) (and she got it, she did)
>
>

Jim Starkey