johnson_dave2003 wrote:

>
>
>When I have a specific need for this kind of throughput need on a
>Firebird project I will do some empirical testing and let you know
>what I find. My original question was out of curiosity, and is not
>representative of any immediate concerns. It sounds like the Firebird
>architecture handles things well internally that are tuned in hardware
>on other platforms.
>
>
>

That was the original design goal of the JRD family. I got fed up with
other DEC developers blaming bad performance on the users' failure to
properly tune the operating system, file system, or database system.
DEC's first database system, DBMS-11, was based on IDMS, and had every
conceivable tuning option. But it always performed like a dog. My goal
was to eliminate all tuning on the theory that computers should be smart
enough to manage themselves. I ended up with a choice of page size and
choice of indexes. Unlike other systems, however, the index search
retrieval algorithm was two phase -- first the system scanned the
index(es) to determine the specific records, then scanned the data pages
in physical order. This eliminated the need to separate index and data
on different spindles, eliminated placement control, and eliminated fill
level. The intermediate state of the retrieval is a sparse bit map, so
if a retrieval potentially used more than one index, the system could
scan all, combining the resulting bitmaps with boolean operations before
looking at any records. This also eliminated the need for the optimizer
to consider different index search strategies, reducing the cost and
complexity of optimization and the danger that the optimizer would pick
the wrong index.

At the conceptual level, Firebird and Oracle have almost nothing in
common. Almost all Oracle performance features are, in fact, work
arounds for Oracle specific performance bugs.