> CREATE CACHED TABLE abc
> a INTEGER IDENTITY PRIMARY KEY ,
> b VARCHAR(1024),
> c VARCHAR(1024),
> d VARCHAR(1024),
> e SMALLINT,
> f DATETIME,
> g DATETIME,
> h DATETIME,
> i VARCHAR(255),
> j INTEGER,
> k INTEGER,
> l INTEGER,
> m CHAR(1));
> CREATE INDEX jindex ON abc (j);

Whats a cached table? One that resides in memory?

> Inserting 75000 rows, Single transaction, ~50Mb data.
> HYPERSONIC = 13 sec
> FIREBIRD = 20.3 sec
> MYSQL = 20.9 sec

makes sense.

> Select ID from abc; returning all 75000 integer IDs
> HYPERSONIC = 1.66 sec
> FIREBIRD = 3.46 sec
> MYSQL = 0.2 sec

How many times did you repeat this, Firebird data would get
cached on the first select and should run faster using the
same query on the second select. Single timings of selects
are meaningless, especially if casched means load the table
into memory.

> Select count(*) from abc where J > 500; returning count of 68000
> (index on column J)
> HYPERSONIC = 1.41 sec
> FIREBIRD = 30.26 sec
> MYSQL = 0.06 sec
>
> Select count(*) from abc where K > 500; returning count of 55000 (no
> index on column K)
> HYPERSONIC = 1.54 sec
> FIREBIRD = 0.25 sec
> MYSQL = 0.06 sec

> Seem like firebird is quite quick at count(*) but slow at selects
> returning large numbers of rows. There dosn't seem to be a way of
> doing "LIMIT" to select only a range of the results either in firebird
> which both the others can do. Any tips?

Confused, Firebird should be awful at a count, since it cannot use an
index, and must visit each row in the table to work out what version it
is. Don't know how you got the above but experience tells me that
Firebird should have given you exactly the same result, index or not.

And you should repeat the query at least twice. And then compare
the results.

Paul