RE: [Firebird-devel] No Auto Undo

[Ann W. H. <aha...@ib...>]

At 09:44 AM 4/30/2004, Paul Beach wrote:

>Yes, SuperServer does have an auto-undo feature.

As does Classic.

>Unless you specify that the transaction should be "no auto undo" which you
>can't except by creating your own transaction parameter block both

GPRE least, supports EXEC SQL SET TRANSACTION NO_AUTO_UNDO;   DSQL doesn't 
recognize the keyword.

>InterBase and Firebird create an undo log that tags along with the 
>transaction.  In many cases, its a good thing because it allows the system 
>to back out changes from a rolled back transaction immediately.

Actually, it's not clear that is a performance gain.  Sometimes yes, 
sometimes no.  It does mean that the transaction that rolled back bears the 
burden of undoing its work which may be more "fair" than leaving the trash 
for the next transaction that reads the record, but its certainly no 
faster.  In fact, it is generally faster for a transaction which has 
already read the page to change it than for the original transaction to 
reread the page and clean up after itself.

>In other cases (large loads, for example) it means carrying an ever
>increasing list of undo actions that will consume memory...

And eventually memory becomes performance.


>However the undo-log at transaction level is is automatically discarded when
>it reaches 500 nodes (10^4-10^6 records?) so as not to consume too much 
>memory.

Which I wonder about because the whole "no auto undo" mechanism was added 
for gbak to keep restores from taking infinite time.


>This however does not apply to stored procedures.

Stored procedures, triggers, and mass update verbs (insert ... select, 
update, delete) are defined by the standard to be atomic, so they must be 
capable of being undone without affecting the transaction as a whole.  The 
undo list was created for those operations.

>If you do plan to roll back changes - using auto-undo will also reduce the
>load on the garbage collector thread....

Or, if you're planning to roll back changes, just take the day off.

>The issue isn't speed, but memory usage, the default auto-undo is more 
>efficient and faster than not using it

Unclear.  At least to me.


Regards,

Ann
www.ibphoenix.com
We have answers.