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.

A datastore input showing attributes, each having the index (Idx in the interface)
Defining indexes in the Read and Commit Mapping of a Data Store

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.

A datastore input showing attributes, each having the index (Idx in the interface)
A Rule requiring an indexed value

     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.

A datastore input showing attributes, each having the index (Idx in the interface)
Index not required on Building because a small set of objects already identified using another value (in this case a spatial search on the geometry)

     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.

A datastore input showing attributes, each having the index (Idx in the interface)
Slow use of outer_ring function

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.

 

A datastore input showing attributes, each having the index (Idx in the interface)
Faster use of outer_ring function