Use Indexes
An index speeds up the identification of data within a Rule or Action.
Specify indexes in the Read and Commit mapping
In the Data Store Read and Commit mapping tab, every attribute within a class has a toggle to allow you to specify whether the attribute should be indexed or not. The primary geometry is always indexed.
Note: For Oracle data any other columns with Oracle indexes on them (including primary keys) will be set to be indexed by default.

If you are using an Attribute to identify features in a Rule or Action, it will need to be indexed.
Identifying features means anywhere that you need to specify a class of objects other than in the Rule or Action’s root node (e.g. using a For All, Existence, Aggregate, Chaining or Loop Over Objects construct within a rule or action).
Indexed Values in Rules
The following example rule is checking that the ID of Road_Section
and the ID for Road
objects match.

Note: If you are doing a spatial search (i.e. a comparison on the geometry) to identify nearby features before subsequently checking an ID, then the index on the ID is not required. You will only need it when the attribute is used as the initial way to select the set of objects.

Note: Indexing attributes uses disk space in the cache, which increases the time it takes to run Open Data Tasks in a Session.
Use the unmodified value when comparing indexed data
Whenever you use an indexed value (this includes the primary geometry) as the first Check That then you should avoid applying any built-in functions to the value.
For the index to work, the Check That needs to run on the raw attribute value itself because this is what has been indexed, not the result of a Built-in function.
For example, the action displayed below will be very slow because we can’t use the spatial index to identify the Admin areas. We are running the outer_ring Built-in function on each geometry first which means that every object in the class will need be tested explicitly, rather than using the index on the geometry to reduce the set.

Instead, by adding an AND node with a Check That before the outer_ring Built-in, we can filter down to the possible Admin Areas using the index. This allows the outer_ring Built-in to make use of the index where it can’t do so directly.
This requires ordering the Predicates efficiently, filtering down the data by having Predicates above the one containing built-ins. See Order Conditions Efficiently for more insight into narrowing down features through Predicate order.
In the example below, the Intersects condition will find all areas that are spatially in contact with the line in some way. From this limited subset, we next get the outer ring of each one and do the comparison.
