Adam wrote:

>> A big part of the performance hit here is occurring because the input
>> file is huge. Processing the entire file (up to half a million
>> records involved) in one call to the SP will cause the undo log to
>> build up and build up until the engine simply abandons it, i.e. all
>> that resource deprivation comes to naught. The undo log is a Good
>> Thing (TM) for a reasonable-sized batch, because it allows the engine
>> to clear out new records in case a rollback happens, thus avoiding
>> the survival of garbage when inserts are abandoned.

Err, well actually, the undo log for a procedure can't be abandoned
because the procedure is considered a single atomic statement - if
it fails, Firebird must be able to remove it and all its side effects.
The undo log for a series of client initiated statements will be
abandoned if it gets too large. The undo log for a single client
statement - including a statement that invokes a procedure will not,
regardless of size.

>>
>> But if the undo log itself is abandoned by the engine because it has
>> consumed more than a reasonable amount of resource, there will be
>> garbage - a lot in this case. These inserts are already going into a
>> table that is pushing the limits, even *without* the gross extra
> garbage.

The good thing is that the undo log is never written to disk, so
removing it just involves releasing memory - very fast since the
memory is released as a pool rather than one entry at a time.

>
> GBak uses a technique to tell Firebird not to maintain an undo log,
> part of the connection or transaction from memory. Could this sort of
> thing be employed here?

No, for the reason above - Firebird must keep the undo log for the
current statement.


Regards,


Ann