Hi,

> Now you've got me curious: does that mean that Firebird transacts data,
> but not the index? The way I understand the situation, is that you have
> to make a trip to each row because the index may already contain data
> from inserts which have been performed after the query's transaction has
> been started or are still uncommitted.

Correct, the index-pages contains also nodes inserted by another transaction
which aren't valid by your current transaction. The index-nodes could also
hold nodes that point to non existing records which needs to be
garbage-collected.

> this is the case: is it
> possible to improve the performance by lowering the isolation level?

No, because the nodes in the index-pages will still be visited.

What may be could help in your case is not using a index at all, but i don't
expect a performance increase to milliseconds.


SELECT
count(*),
finishedStep
FROM
item
WHERE
job + 0 = 22
GROUP BY
finishedStep,
job


Regards,
Arno Brinkman
ABVisie

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Firebird open source database (based on IB-OE) with many SQL-99 features :
http://www.firebirdsql.org
http://www.firebirdsql.info
http://www.fingerbird.de/
http://www.comunidade-firebird.org/

Support list for Interbase and Firebird users :
firebird-support@yahoogroups.com

Nederlandse firebird nieuwsgroep :
news://80.126.130.81