> Furthermore, IIUC, by using classic on a multi-processor CPU, it should
> be possible to get several CPUs to work on it simultaneously by having
> multiple connections to the database. Of course, this will only

actually

> be possible if the inserts are not inter-related, and can easily be
> segmented into different parts.

AND

the insert process in question is CPU bound. If the bottleneck is I/O
speed, then you can add 100 extra processors and get no performance
increase.

In short, not enough information was posted by the original question
asker, so we are just taking a stab in the dark at the usual
candidates. Increasing performance is a scientific operation. It
involves looking at the evidence and establishing a theory based on
that observation, then testing it and making a conclusion. It is too
slow, why? is not really enough information to start.

It is too slow but the Firebird process doesn't appear to be doing
anything, or it is too slow and the Firebird process seems to be
pegged at 100% CPU is a much better starting point, then some
knowledge about the nature of the data, whether it is 1 commit per
inserted record etc can be used to explain why it is taking the time
it takes. After that, look again at the business problem you are
trying to resolve and see whether there are other approaches that can
assist.

On countless occasions, I have taken a process that takes several
minutes and optimised it to a subsecond process. (I am not claiming I
can do 1M inserts per second), but certainly I believe a faster
response is possible.

Adam