Since SPARUL updates are generally not meant to be
transactional, it is best to run these in log_enable (2) mode, which
commits every operation as it is done. This prevents one from
running out of rollback space. Also for bulk updates, transaction
logging can be turned off. If so, one should do a manual checkpoint
after the operation to ensure persistence across server restart
since there is no roll forward log.
To have a roll forward log and row by row autocommit, one may
(3) . This will write constantly into the log which
takes extra time. Having no logging and doing a checkpoint when the
whole work is finished is faster.
Many SPARUL operations can be run in parallel in this way. If
they are independent with respect to their input and output, they
can run in parallel and row by row autocommit will ensure they do
not end up waiting for each others' locks.