Optimizing Repetitive Computations of Database Triggers Within a Transaction

Projet RODINWe study the problem of optimizing costly repetitive evaluations of database triggers within a transaction. We first show that well known incremental rule evaluation algorithms such as RETE or TREAT are inappropriate for that because they do not consider how repetitive triggerings of rules can be caused by the structure of transaction programs. Therefore, their decision of precomputing and caching some expressions in rule conditions for a later reuse can be erroneous. We assume that transaction programs are represented by their flow graph. We then propose an algorithm that, given a transaction's flow graph, and a set of triggers, constructs a compact data structure called a triggering graph. First, for each possible transaction execution, this graph indicates which rules may be triggered. Second, for every rule $r$ capable of being triggered and fired several times, the graph represents the real «influence» of both the transaction and the rules on $r$. This provides the necessary information for deciding which subexpressions of $r$ are most profitable to cache for the considered transaction

Optimizing repetitive computations of database triggers within a transaction

Programme 1 : architectures paralleles, bases de donnees, reseaux et systemes distribues Projet RodinSIGLEAvailable at INIST (FR), Document Supply Service, under shelf-number : 14805 E, issue : a.1995 n.2533 / INIST-CNRS - Institut de l'Information Scientifique et TechniqueFRFranc

Optimizing Repetitive Computations of Database Triggers Within a Transaction

We study the problem of optimizing costly repetitive evaluations of database triggers within a transaction. We first show that well known incremental rule evaluation algorithms such as RETE or TREAT are inappropriate for that because they do not consider how repetitive triggerings of rules can be caused by the structure of transaction programs. Therefore, their decision of precomputing and caching some expressions in rule conditions for a later reuse can be erroneous. We assume that transaction programs are represented by their flow graph. We then propose an algorithm that, given a transaction's flow graph, constructs a compact data structure called a triggering graph. First, for each possible transaction execution, this graph indicates which rules may be triggered. Second, for every rule r capable of being triggered and fired several times, the graph represents the real "influence" of both the transaction and the rules on r. This provides the necessary information for deciding which ..