Gator: An Optimized Discrimination Network for
Active Database Rule Condition Testing
Eric N. Hanson
301 CSE
CIS Department
University of Florida
Gainesville, FL 32611
(904) 3922691
FAX: (904) 3921220
hanson@cis.ufl.edu
Mohammed S. Hasan
301 CSE
CIS Department
University of Florida
Gainesville, FL 32611
msh@cis.ufl.edu
December 1993
TR93036
Abstract
This paper introduces a new discrimination network structure called Gator that is a generalization of
the widely known Rete and TREAT algorithms. Gator can be used as a replacement for Rete or TREAT
in active database rule systems and production system interpreters. In Gator, f/memory nodes that hold
intermediate join results can have two or more inputs, not exactly two inputs as they do in Rete. Gator
is designed as the target structure for a discrimination network optimizer. Algorithms for performing
pattern matching using a Gator network to see if a rule condition has been satisfied are given. Cost
estimation functions for Gator networks based on cardinality, predicate selectivity, and update frequency
information are introduced, and a technique for constructing optimized Gator networks is described. A
Gator network optimizer has been developed, and the optimizer has been tested with simulated inputs.
The results show that in terms of time, Gator can substantially outperform unoptimized Rete networks,
TREAT networks, and optimized Rete networks, often by an order of magnitude. Gator also uses space
effectively, requiring only slightly more space than TREAT and much less then Rete.
1 Introduction
Both production systems and active database systems must perform rule condition matching during execution
to determine which rules to fire. The most successful rule condition testing mechanisms developed for main
memory production systems system are discrimination networks known as Rete [5] and TREAT [12]. Like
production systems, active database systems must also test rule conditions, and we believe some kind of
discrimination network will be the best tool for doing so. However, choosing a good discrimination network
structure is far more important in the active database environment than in mainmemory production systems
because of the volume of data involved, and the fact that some or all of the data may be on secondary storage.
R1.d=R2.d R2.e=R4.e R4.f=R5.f
R) R2 R4 R5
R1.a>17 R5.b="Friday"
R3.g=R2.g
R3)
R3.c="on"
Figure 1: Example rule condition graph.
Previous work has shown that the TREAT algorithm usually outperforms the Rete algorithm [12]. A
recent performance study comparing Rete and TREAT in a database environment showed that neither Rete
nor TREAT always is best, TREAT normally is better than Rete, but sometimes Rete can vastly outperform
TREAT [18]. This lead us to search for a more general structure than Rete or TREAT.
This paper presents a generalized discrimination network structure called the Gator (Generalized TREAT/Rete)
network. Gator networks are general tree structures. Rete and TREAT networks are special cases of Gator.
Gator networks are suitable for optimization because there are a very wide variety of Gator structures that
can perform pattern matching for a single rule. In contrast, there is only a single TREAT network for a
given rule, and Rete networks are limited to binarytree structures.
In many situations the optimal discrimination network will have the form of a Gator network, not a
Rete or TREAT network. Gator networks are also appropriate when there are storage constraints since the
number of internal memory nodes is not fixed as in Rete.
2 Gator network structure
The condition of a rule in a production system or active database system has a structure similar to that of
a relational database query. This structure can be represented as a rule condition graph with one node for
each rule condition element (RCE), and one edge for each join condition. The nodes are decorated with the
selection conditions associated with the corresponding condition elements. An example rule condition graph
is shown in figure 1. This graph is based on some example relations R1 through R5.
Rete, TREAT and Gator networks are all made up of nodes of the following types:
Rete TREAT Gator
al a2 a3 a4 a5 al aa c4 a5 al a2 a3 a4 a5
\\ // /
P2
P2 P31
P3 /Pnode
\Pnode
Pnode
Figure 2: Examples of Rete, TREAT and Gator discrimination network structure.
amemory One amemory holds all tuples from a single relation that match the selection condition of one
RCE.
3memory One 3memory holds combinations of tuples that match a subset of the selection and join
conditions of the rule condition. The tree of nodes rooted at the 3memory defines this subset of the
conditions.
Pnode A Pnode is a special node that takes the place of a 3memory at the bottom of the network. There
is one Pnode for each rule. The tree rooted at the Pnode corresponds to all the selection and join
conditions in the rule condition.
TREAT networks have only amemory nodes. Rete networks have a leftdeep binary tree format and
maintain internal (3memory) nodes, which always have two inputs. Unlike a Rete network, a Gator network
may have internal memory nodes with two or more inputs, not just two. These multipleinput nodes are
called 3memories to be consistent with Rete terminology. Children of a multipleinput node may be a
combination of leaves (amemories) and other multipleinput nodes.
Sample Rete, TREAT, and Gator networks for the rule whose condition graph is shown in figure 1 are
shown in figure 2. The Gator network subtree with three children has the structure of a TREAT network.
3 Virtuala memories
Another property of the Gator network is that a memory nodes may be either materialized, and thus contain
all the tokens that match their selection condition, or they may be virtual, in which case they contain only
their selection predicate but not the tokens matching the predicate. The concept of virtual amemories
has been used in a variation of the TREAT algorithm called ATREAT [6]. Use of virtual amemories for
rule condition matching in Gator is identical to that in ATREAT. Virtual amemories save space since
the matching tokens need not be stored in the memory node. This is particularly important in a database
environment since the underlying data sets can be huge.
4 Rule condition matching in a Gator network
When a base relation tuple is inserted, deleted or modified, rule condition matching must be performed to
see if any rules are triggered or made no longer eligible to fire. The rule condition matching strategy of
Gator is similar to the algorithms for rule condition matching in Rete and TREAT [5, 12]. Gator performs
rule condition matching by propagating lokens through the network. When a tuple is inserted into a base
relation table, an insert token, or "+" token, is created by tagging a copy of the tuple with a + tag. This +
token is then propagated through the network. When a tuple is deleted from a base relation, a delete token,
or "" token, is created similarly and propagated through the network. Modifications are treated as deletes
followed by inserts. The rest of this section covers handling of + tokens and tokens. The algorithms for
processing tokens are described here in a setoriented style that is suitable for use in active database systems.
A tupleatatime, recursive style of the algorithm suitable for mainmemory production systems is presented
elsewhere [7].
In the following discussion, memory nodes of type a and 3 will be referred to together as memory nodes.
Nodes that can have multiple inputs, including 3memories and Pnodes, will be called multiple input nodes.
The term node may be used to describe an amemory, 3memory, or Pnode.
4.1 Handling + tokens
The setoriented version of the Gator algorithm keeps around at each step a set of tokens called a temporary
join result (TR). For processing a + token, this algorithm is implemented in terms of a recursive function,
InsertPlusTempResult. As part of each memory node N in the network, there is a list of pairs, one pair for
each multipleinput node of which N is a child (N may have more than one parent if it is part of a shared
subexpression). Each pair contains the following:
a multiple input node Parent which has N as one of its inputs, and
a plan P for how to join a temporary result inserted into N to the other input nodes of Parent. This
plan is a list of the identifiers of these other nodes, in the order in which they should be joined to the
temporary result.
The list of pairs of the above form is called the parent/plan pair list, or PPPlist. The function Parent(PPpair)
extracts the parent node from the parent/plan pair PPpair. The function plan(PPpair) extracts from PPpair
the list of nodes specifying the join order. Based on this terminology, InsertPlusTempResult is shown in
Figure 3. To initiate match processing when a new token t is inserted into a leaf node LEAF of the Gator
network (LEAF is either a Pnode or an amemory), an initial temporary result TR1 is constructed. TR1 is
a set containing only one token, t. Then InsertPlusTempResult is called with TR1 and LEAF as arguments.
The algorithm InsertPlusTempResult terminates when the temporary result is empty or the final temporary
result is added to the Pnode.
As an example, referring to figure 1 and the Gator network in figure 2, suppose that a tuple was added
to R3 with a value of "on" for attribute c. TR1 would contain an entry for just this tuple. TR1 would arrive
at a3. TR1 would then be joined to a2 via the join condition on the dashed edge from a3 to a2, yielding
TR2. TR2 would similarly be joined to al, yielding TR3. The contents of TR3 would be added to i1, and
then joined to 32, yielding TR4. TR4 would then be added to the Pnode. If any of the temporary results
TR2, TR3 or TR4 were empty upon creation, processing would stop at that point.
Selection of a good join order plan for each input of a multipleinput node is considered later. The nested
loop join method will normally be used to join a TR to a memory node, and will make use of any existing
InsertPlusTempResult(TR,Node)
{
/* TR is a temporary result.
Node is a memory node or Pnode in a Gator network. */
If TR is empty, return.
Insert the tokens in TR into the collection of tokens
belonging to Node.
If Node is a Pnode,
adjust the rule agenda if necessary, and return.
For each parent/plan pair x in PPPlist(Node) {
For each node y in plan(x),
in order from first to last,
{
/* Join the current temporary result to the next
memory node specified by the join order plan,
forming the next temporary result. */
TR = join(TR,y)
}
/* Insert the final temporary result into the
multiple input node for which
new matching tokens are being found. */
InsertPlusTempResult(TR,Parent(x))
Figure 3 Procedure inserting a temporary resultinto a node
}
Figure 3: Procedure for inserting a temporary result into a node
index on the join attribute of the memory node. A sortmerge or other join strategy could be used sometimes
if appropriate.
4.2 Handling tokens
Handling (delete) tokens is slightly different from handling of + tokens. The standard delete optimization
familiar from implementations of Rete is used. This optimization does not do joins during deletions. Rather,
when a token t enters a node, the token is deleted from the node. Then, if that node feeds into a multiple
input node, the tokens in the multiple input node are scanned to see if they contain t as a component. If
so, they are deleted. In turn, more tokens are generated and passed to the successor of the multiple input
node. Detailed algorithms for tokens are not presented.
A discussion of how Gator supports negated condition elements like those that can be specified in OPS5
[2] is given elsewhere [7]. To perform well, the Gator rule condition matching strategy needs a Gator network
with a good structure. How to find an efficient network is the subject of the next section.
5 Optimization of Gator networks
The key parts of an optimization strategy for building a good Gator network are computation of costs of
partial solutions, and search strategies and heuristics for building new partial solutions from smaller partial
solutions. These issues are addressed below.
5.1 A strategy for optimizing Gator networks
The optimization algorithm is a dynamic programming algorithm which progressively builds a set of larger
networks by combining smaller networks that have already been created. It starts by creating a set of
networks of size one. It then builds networks of size i, iterating i from 2 up to n, where n is the number of
nodes in the rule condition graph.
During the iteration when the algorithm is creating the networks of size i, all the networks of size less
than i have already been created. The algorithm takes all possible pairs of already created networks such
that the sum of the sizes of the elements of the pair is equal to i, then checks whether the networks can be
combined, and after combination whether the combined network is the optimal one. Networks cannot be
combined unless they satisfy the disjointness constraint, which states that their respective sets of RCE's
must not overlap. The combined network is considered optimal if it is the cheapest one found so far for the
subset of the nodes in the rule condition graph corresponding to the leaf nodes of the combined network. If
the combined network of size i is optimal, it is added to the set Nets[i], otherwise it is discarded.
The algorithm uses the following rules to combine networks:
Join: Combine two memory nodes m and m' by creating a single twoinput node 3 with the other two nodes
as inputs.
Absorb: Combine a node m and a multipleinput node 3 by adding m as another input node of 3. If both
m and 3 are multipleinput nodes, then each of them can absorb the other, so there are two ways to
apply this rule.
Merge: Combine two networks rooted at 3 nodes m and m' by merging m and m' into a single 3 node.
This new P node will have as its children all the children of m and m' combined.
A graphical representation of the rules is shown in figure 4.
In order to limit the number of subnetworks generated, the following heuristics are used:
Connectivity Heuristic: Do not combine two Gator networks unless there is an explicit join between them
in the rule condition graph.
In other words, do not combine a Gator network nl with a Gator network n2 if there is no edge between
the subgraph of the rule condition graph corresponding to nl, and the subgraph corresponding to n2. In the
case where the rule condition graph is not connected, dummy join edges with i .. " predicates are added
until the graph becomes connected. These dummy edges are placed so that no cycles are added to the graph.
A caveat to the connectivity heuristic is that the optimization algorithm proposed here assumes that
the rule condition graph is acyclic. If there are cycles in the graph, edges will be removed until no cycles
remain before optimization starts. Conditions corresponding to the removed edges will be added to the
Join 0 + 0 =
Absorb Q +
Merge \ O \ \
Figure 4: Graphical representation of rules for combining Gator networks.
Gator network chosen by the optimizer so that rule condition matching will function correctly. Better ways
to handle cyclic and unconnected rule condition graphs await further study.
Lowest Cost Heuristic: In the case where there already is a network corresponding to the same set of
condition elements as the network just created, and the existing network costs no more than the new
network, discard the new network.
The optimization algorithm is described in detail in figure 5. Line 2 of the algorithm initializes the set of
networks of size 1. Line 3 starts the iteration; at iteration I, the set of networks of size I, Nets[I], is filled. To
create a network of size I, a network of size J and another of size (IJ) are combined. To avoid overlapping,
J is varied from 1 to [] (line 4). Lines 7 and 8 scan every member of sets Nets[J] and Nets[IJ]. Line 9
checks the connectivity and disjointness constraints. If the two networks satisfy these constraints, they are
combined in line 10, after searching through all four possible combined networks. Line 11 checks if there is
already a network of size I covering the same subgraph. If there is one, the cheaper of the two networks is
kept and the more costly one is deleted (line 1416). Since there is only one subgraph of size equal to the
size of the rulegraph, namely, the rulegraph itself, there will be only one member of Nets[n]. That is the
optimum network (line 1718).
Gator optimize(RuleCond rule)
{ Gator INet,JNet;
Nets netsJ,netsIMinusJ,*NetsArray;
Gator T,T1;
(0) n = sizeOf(rule);
(1) initialize NetsArray to size n
(2) Initialize NetsArray[1];
(3) for I= 2 to n do
(4) for J = 1 to ['] do
(5) netsIMinusJ =NetsArray[IJ];
(6) netsJ = NetsArray[J];
(7) for each JNet E netsJ do
(8) for each INet E netsIMinusJ do
(9) if( isConnected(INet,JNet) && isDisjoint(INet,JNet))
(10) T = combine(INet,JNet,rule);
(11) if(there is already another network for the same rule subgraph
as the rule subgraph corresponding to T)
(12) T1 = that other network;
(13) if(T is cheaper than T1)
(14) add T to NetsArray[I]; remove T1 from NetsArray[I];
(15) else
(16) delete T;
(17) T =the only network from NetsArray[n]
(18) return T;
}
Figure 5: Gator network optimization algorithm
In the earlier discussion of how the match is performed using a Gator network, it was mentioned that
there is a join order plan associated with each memory node N for each multiple input node to which N
is an input. During optimization, this plan will be constructed as follows. Let N be an input node of a
multiple input node p. When a temporary result TR1 enters N, TR1 is joined to a sibling of N to form
TR2, then TR2 is joined to another sibling of N to form TR3, and so on until no siblings remain. The join
order plan is built so that TRi+l is always formed by joining TRi to the remaining sibling S of N such that
(1) TRi has a join edge to S in the rule condition graph, and (2) the TRi+l value with the smallest expected
cardinality is generated. TRi is said to have a join edge to sibling S if the subgraph of the rule condition
graph corresponding to TRi, and the subgraph of the rule condition graph corresponding to S are linked
directly by an edge.
The procedure described above uses a heuristic to construct a reasonably good join plan quickly. An
alternative would be to use a query optimizer to decide the join plan, but that would be prohibitively
expensive since construction of the plan is part of the larger optimization process to build an optimized
Gator network. Running a query optimizer hundreds or thousands of times as part of optimizing the Gator
network for a single rule would simply take too long to be feasible. Also, since the initial temporary result
coming into N is likely to be small, it will usually be best to join that temporary result to a sibling of N as
the first step because that will tend to make the next temporary result small as well.
This concludes the discussion of the search strategy for constructing Gator networks, pruning bad subnet
works, and eventually returning the best network. Even though a very large number of Gator networks and
subnetworks are built during the optimization process, the process still normally terminates in a reasonable
amount of time (less then a few seconds for one rule) because typical rule condition graphs have only a few
nodes. It will be very rare for a rule condition graph to have more than ten nodes. Most will have one to
five nodes.
The optimization technique discussed above has been implemented as part of a simulator to compare
Gator with Rete and TREAT. Randomized optimization strategies such as simulated annealing, iterative
improvement, and twophase optimization [9, 10] can also be applied to Gator networks, and are also being
investigated [13]. The search space for Gator network optimization grows with the size of the rule condition
graph even more rapidly than the size of the search space for query optimization grows with the size of the
query graph, since Gator network inner node fanout can be greater than two while query graph inner node
fanout is always two. Because of this, randomized optimization techniques may be more important for Gator
network optimization than they are for query optimization. We have observed that dynamic programming
takes an impractical amount of time (greater than one minute) when the rule condition has 12 or more
condition elements.
This section assumes all amemories in a Gator network are stored, not virtual. Developing a process
for building optimized Gator networks that may contain virtual amemories is a subject for future work. At
this point, it is suggested that if virtual amemories are to be used, a postprocessor can be applied to the
Gator network produced by the optimizer to decide which nodes should be virtual. Below, the functions for
estimating the cost of a piece of Gator network are discussed in detail.
5.2 Cost functions
The question that must be answered is, what does a Gator network cost? First, the units of cost will be
update frequency times elapsed time. To see why this is important and how it can lead to good Gator network
structures, observe the following. If no tokens ever enter the memory nodes at the leaves of a Gator network,
then its cost is zero, so its structure is not important. If the tokens frequently enter one leaf node al but not
the others, then it will probably be appropriate to construct any Gator network for the infrequently updated
nodes, as long as it has a 3memory at the bottom, and then join a1 to that 3memory. This will require
only a oneway join when tokens enter a1, rather than a multiway join.
Since the optimizer will operate in a database management system environment, the catalog statistics
about relation size, attribute cardinality, and attribute value distribution will be available. These statistics
can be used by the optimizer to compute estimates of selection predicate and join predicate selectivity, just
as they are used by query optimizers [15]. The most important variable in the problem of discrimination
network optimization that is different from those used for query optimization is update frequency. Relative
frequency of updates to different memory nodes in a discrimination network can have a major impact on
the choice of the optimal structure. It is assumed that the database system keeps the insert and delete
frequencies of each relation in the system catalogs. Modifications of existing records are treated as deletes
followed by inserts. The frequency might be in units like "total number of operations performed in the last
24 hours." The discussion below gives the parameters involved in computing the cost of a Gator network,
and then develops formulas for estimating the total cost of a network.
5.3 Parameters used
The following are the parameters that are needed to estimate the cost of a Gator network. Unless stated
otherwise, N represents any kind of Gator network node (a, 3 or Pnode).
Fi(N) is the frequency with which new + tokens enter a node and update it.
Fd(N) is the frequency with which new tokens enter a node and update it.
S(N) is the cardinality of a given node.
Pages(N) is the number of pages occupied by N.
Sel(a) is the selectivity of the predicate associated with the amemory node a. This value can be estimated
from catalog data using standard techniques [15].
JSF(Ni, N2) is the estimated join selectivity factor between a pair of nodes N1 and N2. It is an estimate
of the following value:
S(Ni N2)
S(Ni) S(N2)
I/Oweight is the time to do a disk read or write.
CPUweight is the CPU time spent to insert or delete a tuple in a memory node or perform a predicate test
on a tuple or between a pair of tuples.
Reln(a) is the relation from which amemory node a is derived. The frequencies Fi(Reln(a)) and Fd(Reln(a))
of updates to this relation can be obtained from statistics maintained in the catalog.
Cost(N) is the total cost associated with the subnetwork rooted at N.
LocalCost(N) is the cost associated with only local processing at N (i.e. not including the cost of its
children).
In the cost formulas to follow, it will sometimes be necessary to estimate the number of pages touched
in a memory node of size m blocks when k records in it are accessed at random. For this the following
approximation to the Yao function [19] is used:
f m(1 (1 /m)k) if c> 1
Yao(m,) k if k <
In the cost functions that follow, unless stated otherwise, it is assumed that any disk pages read are not
already in the buffer pool.
5.3.1 Total cost of a Gator network
The total cost of a Gator network with Pnode P is Cost(P). The Cost function is recursively defined. Its
implementation for each of the different node types follows.
5.3.2 Cost computation of a nodes
The a nodes will either be stored on a single page, or organized using a clustered index on the primary key.
If an index is used, it is assumed that no index I/O will be needed because the index will be in the buffer
pool. Hence, one disk read and one disk write are required to do either an insert or delete. Since only one
tuple is touched, only one CPUweight cost is incurred. This leads to the following formula:
Cost(a) = LocalCost(a) = (2 I/Oweight + CPUweight) (Fi(a) + Fd(a))
The insert and delete frequencies of the a node, Fi(a) and Fd(a), are given by these formulas:
Fi(a) = Fi(Reln(a)) ( Sel(a)
Fd(a) = Fd(Reln(a)) Sel(a)
5.3.3 Cost computation of 3 nodes
The cost of a 3 node is a function of the cost of processing tokens propagated from each of its children.
This involves join costs for doing the matching, plus costs to update the stored copy of the 3 node itself.
Associated with each child c of a 3 node is a join plan that gives the sequence in which join operations
should be performed when a temporary result TR arrives at a child c of a 3 node. The join plan is the
sequence (mi, m2, ..., nmk), where mi through mk are the children of 3 except for c. When TR enters c, then
the following sequence of operations is performed:
TR = TR N mi
TR = TR N m2
TR = TR N mk
At this point, the contents of TR are inserted into or deleted from 3, as appropriate.
Each child of a 3 node either fits on one page or has a secondary index (or indexes) for faster access on
the join fields. The indexes on the child nodes are used when the TR is joined with them. The cost of a P
node includes the cost of its children, the cost of updating the node itself, and the cost of performing joins
when temporary results are propagated from its children.
Cost(3) = LocalCost(3) + Cost(N)
NEchildren(p)
LocalCost(3) = F(N) PerChildInsCost(N, 3) + Fd(N) PerChildDelCost(N, 3)
NEchildren(p)
The function PerChildInsCost(N, f) accounts for the cost to process a temporary result containing one +
token arriving at f from child N. This represents a simplifying assumption that if a temporary result TR
arrives at 3 from N, each token in TR will be processed individually. Not making this assumption would make
the cost estimation functions significantly more complex. The function PerChildDelCost(N, f) accounts for
the cost to process a temporary result containing a single token arriving at f from child N. The function
PerChildInsCost(N, f) is most easily represented as the following procedure:
PerChildInsCost(N, f) {
(size, cost) = JoinSizeAndCost(N, f)
return( cost + updateCost(f, size)
I
The body of this procedure calls a function JoinSizeAndCost(N, f) that returns a pair of numbers which
are the expected size of the last temporary result generated after a token comes into N, and the cost of
generating that temporary result. The function JoinSizeAndCost(N, f) is shown in figure 6. Another
procedure called in PerChildInsCost is UpdateCost(P,TRsize), and this procedure gives the time required
to update a multipleinput node 3 to reflect the contents of a temporary result of size TRsize that is to be
propagated through P. The UpdateCost function is shown in figure 7.
JoinSizeAndCost(N, 3) {
TRsize = 1 /* initial temporary result size */
cost = 0
L = plan(N, 3) /* initialize join order list */
previousNode = N
m = first(L) /* let m be first element of list L */
while ( m f Null ) {
if m fits on one page then
cost = cost +I/Oweight + CPUweight S(m). TRsize
else /* m is bigger than one page, so assume */
/* only tuples on one page of m are examined */
/* for each tuple in TR. */
cost = cost +I/Oweight min(pages(m),TRsize) +
CPU eight tuplesPerPage(m). TRsize
TRsize = JSF(previousNode, m)TRsize.S(m)
L =rest(L) /* set list L to remaining list elements
after the first element */
previousNode = m
m = first(L)
}
return(TRsize,cost)
}
Figure 6: When a temporary result TR is propagated out of a node N that is an input node to a node 3,
TR must be joined to the other input nodes of 3. This procedure computes both the cost of doing these
joins, and the size of the final temporary result generated after doing the joins.
UpdateCost(P,TRsize) {
/* A TRsize value less than one is significant
since small join selectivities can produce temporary
results that are small on average. The Yao function
takes this into consideration. */
cost = Yao(pages(3),TRsize) 2 I/Oweight + TRsize CPUweight
/* If TR is larger than one page, add the cost to
allocate or delete pages in 3. */
if TRsize >1
StuplesPerPage(t)
TRsize 2 IlOweight
cost = cost + tupleP e 2 I/Ow t
return(cost)
Figure 7 Function to compute cost to update a memory node
Figure 7: Function to compute cost to update a 3 memory node.
The procedure PerChildDelCost(N, 3) has a slightly different structure than the procedure
PerChildInsCost(N, 3). It is assumed that the standard delete optimization discussed earlier that is often
used in Rete and TREAT implementations is employed.
The function PerChildDelCost(N, 3) must account for the cost to read all pages of the 3 node (no index
is available to support this operation), plus the cost to write pages of / that contain tokens with components
from child N. Each token in 3 must be examined, so one CPUweight factor must be paid for each token in
3 as well. This function is most easily represented as the following procedure:
PerChildDelCost(N, /) {
(size, cost) = JoinSizeAndCost(N, 3)
return( (Yao(Pages(3), size) + Pages(3)) I/Oweight
+S(3) CPUweight)
5.3.4 Pnode cost
The Pnode is not stored permanently on durable storage, and it is emptied when the rule associated with it
is fired. The formula for the cost of a Pnode is similar to the one for a 3memory except the cost to update
the contents of the Pnode is a CPUonly cost [7]. For brevity, the detailed cost functions for Pnodes are
omitted.
5.3.5 Estimating update frequency of 3 nodes
Formulas given previously have used the frequency functions Fi and Fd on 3 nodes. To finish the story it is
necessary to show how Fi and Fd for 3 nodes can be estimated. The value of Fi(P) is the relative frequency
of propagation of compound + tokens out of 3 compared with other nodes. Similarly, the value of Fd(3) is
the relative frequency of propagation of compound tokens out of P. An estimate for Fi is:
Fi(3)= F(N) JoinSize(N, 3)
NEchildren(P)
where JoinSize(N, P) simply returns the size value from the pair of values returned by JoinSizeAndCost(N, 3).
Similarly, an estimate for Fd is:
Fd(3) = Fd(N) JoinSize(N, 3)
Nechildren(P)
This section has presented a search strategy for building an optimized Gator network, and functions for
estimating the cost of a Gator network to help guide the search. Though the cost estimates are approxi
mate, they are useful for purposes of comparing relative network cost. Query optimizers based on similar
approximate cost estimates have proven highly effective [15].
6 Optimizer implementation and evaluation
A Gator optimizer has been implemented in a simulated database , ii..i ......I ['] Inputs to the optimizer
are a collection of relation descriptors, and a collection of rule descriptors. A relation descriptor describes
a relation though the actual tuples of the relation are not stored. A relation description includes, among
other things, the number of attributes, cardinality, update frequencies, etc. for a relation. A rule descriptor
describes a rule in the form of a rule graph. Each node in the rule graph represents a tuple variable, and
each edge represents a join. Among the parameters of a node is the predicate selectivity, defined as Sel(a)
in the cost model. Parameters of an edge include the JSF of the join represented by that edge. A number
of parameters are given as input to the database simulator, which creates relation and rule descriptors in
a random fashion using those parameters. The behavior of the optimizer is estimated for varying database
conditions by changing the input parameters to the simulator.
Five different types of networks have been created and compared for a number of rules. These are
Gator, Best Rete, Best TREAT, Worst Rete, and Overall Worst. Rete networks are created by modifying
the combination methods of the optimizer, and the worst networks are created by optimizing for maximum
instead of minimum cost. The Worst Rete network is the network with the maximum cost having a binary
tree structure. Similarly, the Overall Worst network is the network having a Gator structure but with
maximum cost. The ..i1 networks are created to show the worst possible network cost that might by
chance be observed without optimization.
The performance of a network is characterized by the time it takes to test the rule condition using that
network, and the disk or memory space the network occupies. The average time for the rule condition
matching through a network is estimated as the cost of that network, as defined in the Gator cost model.
The cost is a product of two terms, namely time (CPUweight and IOweight) and frequency (Fi and Fd). Thus
the cost is a dimensionless quantity. Although it does not have any unit, it is nonetheless a measure of time
that is spent for rule condition matching through the network. This measure is useful only to compare the
relative performance of networks.
In addition to the cost, a measure of relative merit of a network is its expected space requirement. Space
occupied by a network is estimated as the sum of the page() quantity of all of its nodes, which gives the
number of disk pages occupied by the network. The performance of the optimizer in terms of optimization
time is also assessed.
6.1 Cost of a network
The following table shows the costs of five types of networks for five randomly generated rule graphs. Each
rule graph has five rule condition elements. In general, it has been found that the cost of a Gator network
is always less than those of a Rete and a TREAT network for the same rule. The difference in cost varies;
in most cases it is large.
Cost Comparison for Sample Networks
Rule Size Gator TREAT Best Rete Worst Rete Worst
0 5 1.44E+06 1.48E+06 3.15E+09 2.75E+12 2.75E+12
1 5 2 ',1 +', 3.03E+05 1.55E+08 1.44E+11 1.44E+11
2 5 9.46E+04 2.87E+05 2.27E+10 5.43E+11 5.43E+11
3 5 1.63E+01 4.11E+01 9.16E+02 2.83E+04 2.83E+04
4 5 5.17E+04 1.06E+05 2 ". +d 9.55E+10 9.55E+10
It is not surprising that the Gator network chosen has minimum cost for each rule. But the difference
in cost between different types of networks is interesting. In the above table, the difference in cost between
different networks for all rules except rule 2 and 3 are similar. Rule 2 shows a large difference in costs
and rule 3 shows a small difference. As shown in the cost model, network cost is a function of a large
number of parameters, and it is difficult to isolate the affects of these parameters analytically. Therefore, an
NETWORK COST VS. SELECTIVITY THRESHOLD(A3 = 0.2 B3 = 0.8)
U,)
o 2000 
O
1500
LLU
z
1000 TREAT
500
GATOR
0 
0 0.002 0.004 0.006 0.008 0.01 0.012 0.014 0.016 0.018
SELECTIVITY THRESHOLD
Figure 8: Network Cost increases as Selectivity(value) of predicates increase.
experimental approach has been taken to study the effect of various database parameters on the performance
of the discrimination network, particularly on the cost value of the network. The following discussion
illustrates what was observed.
6.2 Predicate and join selectivity
Selectivity of the predicate associated with a tuple variable (RCE) is defined as the fraction of tuples in the
relation associated with the tuple variable that satisfy the predicate. In figure 8, the cost of networks is
plotted against the SeleciThresh a parameter to the simulator. Nodes having small selectivity are assigned
selectivity value randomly within the range (O,SeleciThresh ]. Therefore, larger value of SeleciThresh means
larger value of selectivity for predicates and hence more tuples filtered toward the a nodes of the network.
Parameter B3 is the fraction of nodes having small selectivity. The parameter A3 (= 1 B3) is the fraction
of the nodes having large selectivity, which is randomly chosen within the range (SelectThresh,1.O].
At small values of SeleciThresh, the cost of Gator, TREAT and Rete networks are low, indicating that
the discrimination networks do not see much activity. One interesting phenomenon in this region is that the
Rete network beats TREAT, and at very low selectivity values, Gator is in fact a Rete. This is expected
because the 3 nodes are very small in this region. The cost to maintain the 3 nodes is offset by the savings
in the cost of joins. As A3 [= 0.2, only a tiny fraction of nodes have poor selectivity, most of the nodes are
highly selective. TREAT does not take advantage of this and performs poorly. Whereas Rete keeps these
profitable 3 nodes and outperforms TREAT. However, the difference in cost is small and not very significant.
The superiority of Gator becomes startling at higher values of selectivity threshold. The cost of Gator
increases almost linearly with selectivity threshold, a very shallow slope, whereas Rete and TREAT show
a vastly more rapid increase. After a point TREAT outperforms Rete and keeps doing so as the value of
SeleciThresh increases. This also supports the fact that at large values of selectivity, most of the tokens
will propagate through the selection predicates. Keeping this large volume of incoming data in 3 nodes is
expensive compared to the profit they yield. Therefore, TREAT, which does not keep these 3 nodes, is
expected to perform better than Rete. Gator, however, keeps only those / nodes which provide more profit
than their cost of maintenance, thereby outperforming both Rete and TREAT by an order of magnitude in
cost.
Figure 9 shows the effect of average JSF on the network cost. The effect of JSF over network cost is
similar to that of predicate selectivity. Both the selectivities indicate the permeability of the filtering action
of the discrimination network. Thus, the larger the values of the parameters, the more the data flow, and
consequently, the higher the cost of the network.
Figure 10 demonstrates the effect of varying the average JSF of the join conditions on the total space (in
pages) occupied by the memory nodes in the network. A very similar graph is observed if selection predicate
selectivity (selectivity threshold) is varied on the x axis instead of JSF. Intuitively, a TREAT network should
have the lowest space requirement, Rete the highest, and Gator in between. The data obtained in this regard
support this intuition. There is another interesting observation: the space requirement of Gator is near to
the minimum, almost equal to that of TREAT. This is a very important result. One of the reasons for which
TREAT is favored for disk bound production systems is its low space requirement. These results show that
the space requirement of Gator is very close to that of TREAT, while its performance is much better than
COST VS. JOIN SELECTIVITY
I
0 TREAT
o103
102
GATOR
10
0 0.001 0.002 0.003 0.004 0.005 0.006 0.007 0.008 0.009 0.01
AVERAGE JSF
Figure 9: Effect of JSF on Network Cost
TREAT, as is suggested by the difference in cost values. This fact brings out Gator as the clear winner over
Rete and TREAT, considering space and time performance together. The low space requirement of Gator
can be explained by the cost functions discussed before. A major portion of the cost of the 3 nodes, the
most expensive among all nodes, is the UpdateCost, which depends on the size of the node. Large 3 nodes
take a lot of time to maintain as tokens flow through the network. Hence, the optimizer avoids creating large
3 nodes.
6.3 Rule size and optimization time
The number of RCE's in a rule determines the performance of the optimizer. The size of the search space
of the optimizer increases exponentially with the number of the nodes in the rule graph. But the optimizer
keeps the growth of its search space in check by pruning out suboptimal subnetworks using constraints and
heuristics. It has been found that, as shown in figure 11, the optimizer can find the Best Gator network
within one second for rules with up to five RCE's. At 11 RCE's, it takes roughly one minute to find the
VARIATION OF SPACE REQUIREMENT OF THE NETWORK
106
LU
S105 RETE
10
103
0 0.001 0.002 0.003 0.004 0.005 0.006 0.007 0.008 0.009 0.01
AVERAGE JSF
Figure 10: Network space vs. average JSF
best Gator network. Rules in any database will rarely contain more than 12 RCE's, thus performance of
the dynamic programmingbased optimizer will be adequate for most situations. Randomized optimization
methods are being investigated to handle rules with more than 12 RCE's [13].
6.4 Generality of the Gator network structure
One of the targets of the design of the Gator network optimizer was that it will not favor any particular
discrimination network configuration; it will always choose the best, in terms of network cost, regardless
of whether it is Rete, TREAT or anything in between. Results obtained from the optimizer show that the
optimizer is indeed choosing the cheapest network without favoring any particular configuration. It has been
found that, at very low level network activity, characterized by small values of update frequency, selectivity
and JSF, Rete style networks are better than TREAT style networks. By the term Rete style, we mean
networks where most 3 nodes have 2 inputs. These networks have almost a binary tree structure. When it
is a left deep or right deep binary tree, it is a pure Rete network. As the level of database activity increases,
OPTIMIZATION TIME VS. RULE SIZE
150
< 100
(GATOR
O
RETE
0
2 4 6 8 10 12 14
NUMBER OF RCE
Figure 11: Time taken to produce optimized Gator and Rete networks using dynamic programming vs. the
number of rule condition elements. A TREAT network can be constructed in a fraction of a second without
optimization for rules with any reasonable number of RCE's.
TREAT style networks seem to be a better choice. These networks have fewer 3 nodes, thus most of the
3 nodes have multiple inputs. This transition of choice is smooth and consistent. As one or more of the
parameters are varied from low to high values, the transition from one type of network to the other can
be seen. Figure 12(b) shows the network for the rule graph in figure 12(a) when selectivity threshold is
very small, .0008. All the 3 nodes have two inputs, except one that has three inputs. In figure 12(c), the
selectivity values are larger, which has eliminated one 3 node, in addition to rearranging other a and 3
nodes. Figure 12(d) has only three 3 nodes, each taking inputs from three a nodes.
7 Related work
The Gator network is a descendant of Rete and TREAT [5, 12]. The Gator network is only useful with an
optimizer or at least a good set of heuristics for constructing a network for a particular rule or set of rules. The
feasibility of generating an optimizer for Rete networks was demonstrated by Ishida [11]. Use of heuristics to
construct a good discrimination network for testing active database rule conditions was discussed by Fabret
1 a(0) o(4) (1l) a(3) 0(5) a(6) o(7) a(2)
2 5
36
Rule Graph (a)
/ Network when SelectThresh= 0.005
u(4) a(0) u(6) U(5) a(1) a(7) a(2) u(3) A = 0.4 B = 0.6
P (c)
S\a(0) a(4) (1) a(2j (7) o(( ) ) (3) a(6)
/P Network when SelectThresh = 0.0008
A3= 0.4, B3= 0.6
P P
() Network when SelectThresh = 0.02
p A3 = 0.4, B3 = 0.6
(d)
Figure 12: Variation of network structure depending on rule condition selectivity.
et al. [3], but that work did not introduce a general discrimination network structure, a detailed cost model,
or a searchbased optimization strategy like the ones given in this paper. The results presented in this paper
build on fundamental query optimization and query plan cost estimation techniques [15]. Work on extended
query optimization problems such as optimizing large join queries and considering bushy join trees [9, 10] is
also relevant. There is also some similarity between the problem of optimizing the discrimination network
for a collection of rules, and optimizing an execution plan for simultaneously evaluating a set of queries
[4, 14, 16]. A major difference between work on discrimination network optimization and query optimization
is that in discrimination network optimization, update frequency is a key variable. Moreover, discrimination
network construction requires making decisions about whether or not to construct memory nodes, and that
requires considering the cost of maintaining that memory node. In query processing there is no need to
consider update frequency, and their is nothing analogous to maintaining a memory node.
8 Summary and conclusion
This paper has introduced a new, generalized discrimination network structure called Gator that can be used
to test rule conditions in active databases and production systems. Gator is extremely general, capturing
both the Rete and TREAT structures as special cases. The key difference between Gator and Rete is
that in Gator, a multipleinput (3) node can have more than two inputs. Because the Gator structure is
so general, an optimizer is essential to pick a good structure for a rule depending on the environment. A
dynamic programming optimization strategy somewhat akin to a query optimization method [15], but taking
into consideration additional factors such as update frequency and memory node size, has been designed,
implemented, and tested in a simulation. Results show that Gator can be expected to outperform Rete and
TREAT by and order of magnitude or more in terms of time in some cases. Gator also uses space effectively
since it is reluctant to materialize large 3 nodes. The dynamic programming strategy for Gator optimization
is currently workable for rules with up to roughly 11 condition elements.
Preliminary results from a study of optimization of Gator networks using randomized algorithms shows
that it is feasible to build optimized networks for rules with up to 24 rule condition elements in a few seconds
[13]. Plans for future work include optimization of Gator networks for multiple rules with subexpression
sharing, extending the Ariel system to use the Gator algorithm instead of the currently used modified
TREAT strategy, and then testing Gator in a real database environment. In addition, a variation of Gator is
being considered that would support a new match strategy called collectionoriented match [1]. A collection
oriented Rete strategy has given up to a 1000times speedup for some mainmemory OPS5 applications.
Finally, parallel versions of Gator and collectionoriented Gator are also being considered.
References
[1] Anurag Acharya and Milind Tambe. Collectionoriented match: Scaling up the data in production
systems. Technical Report C'IUCS92218, CarnegieMellon University, December 1992.
[2] L. Brownston, R. Farrell, E. Kant, and N. Martin. Programming Expert Systems in OPS5: an Intro
duction to RuleBased Programming. Addison Wesley, 1 .
[3] Francoise Fabret, Mireille Regnier, and Eric Simon. An adaptive algorithm for incremental evaluation
of production rules in databases. In Proceedings of the VLDB Conference, 1993.
[4] S. Finkelstein. Common expression analysis in database applications. In Proceedings of the AC if
SIC, iOD International Conference on Management of Data, pages 235245, 1982.
[5] C. L. Forgy. Rete: A fast algorithm for the many pattern/many object pattern match problem. Artificial
Intelligence, 19:1737, 1982.
[6] Eric N. Hanson. Rule condition testing and action execution in Ariel. In Proceedings of the AC if
SIC, iOD International Conference on Management of Data, pages 4958, June 1992.
[7] Eric N. Hanson. Gator: A discrimination network suitable for optimizing production rule matching.
Technical Report CISTR00793, University of Florida CIS Dept., February 1993. Available by anony
mous ftp from ftp.cis.ufl.edu. See README file under /cis/techreports.
[8] Mohammed Hasan. Optimization of discrimination networks for active databases. Master's thesis,
University of Florida, CIS Department, November 1993.
[9] Yiannis loannidis and Younkyung Cha Kang. Randomized algorithms for optimizing large join queries.
In Proceedings of the AC if SIC, iOD International Conference on Management of Data, pages 312321,
May 1990.
[10] Yiannis loannidis and Younkyung Cha Kang. Leftdeep vs. bush trees: An analysis of strategy spaces and
its implications for query optimization. In Proceedings of the AC if SIC, iOD International Conference
on Management of Data, pages 168177, May 1991.
[11] Toru Ishida. Optimizing rules in production system programs. In Proc. AAAI National Conference on
Artificial Intelligence, pages 699704, 1988.
[12] Daniel P. Miranker. TREAT: A better match algorithm for AI production systems. In Proc. AAAI
National Conference on Artificial Intelligence, pages 4247, August 1 .
[13] Jayashree Rangarajan. A randomized optimizer for rule condition testing in active databases. Master's
thesis, University of Florida, CIS Department, December 1993.
[14] A. Rosenthal and U.S. Chakravarthy. Anatomy of a modular multiple query optimizer. In Proc. of
VLDB Conf., pages 230239, 1988.
[15] P. Selinger et al. Access path selection in a relational database management system. In Proceedings of
the AC if SIC, iOD International Conference on Management of Data, June 1979. (reprinted in [17]).
[16] Timos Sellis. Global query optimization. AC if TODS, 13(1):2352, 1988.
[17] Michael Stonebraker, editor. Readings in Database Systems. Morgan Kaufmann, 1988.
[18] Yuwang Wang and Eric N. Hanson. A performance comparison of the Rete and TREAT algorithms
for testing database rule conditions. In Proc. IEEE Data Eng. Conf., pages 8897, February 1992.
[19] S. B. Yao. Approximating block accesses in database organizations. Communications of the AC i!
20(4), 1977.
