Access Method Strategies
The operators associated with an operator class are identified by "strategy numbers", which serve to identify the semantics of each operator within the context of its operator class. For example, B-trees impose a strict ordering on keys, lesser to greater, and so operators like "less than" and "greater than or equal to" are interesting with respect to a B-tree. Because PostgreSQL allows the user to define operators, PostgreSQL cannot look at the name of an operator (e.g., < or >=) and tell what kind of comparison it is. Instead, the index access method defines a set of "strategies", which can be thought of as generalized operators. Each operator class shows which actual operator corresponds to each strategy for a particular data type and interpretation of the index semantics.
B-tree indexes define 5 strategies, as shown in Table 14-1.
Table 14-1. B-tree Strategies
|less than or equal||2|
|greater than or equal||4|
Hash indexes express only bitwise similarity, and so they define only 1 strategy, as shown in Table 14-2.
R-tree indexes express rectangle-containment relationships. They define 8 strategies, as shown in Table 14-3.
Table 14-3. R-tree Strategies
|left of or overlapping||2|
|right of or overlapping||4|
GiST indexes are even more flexible: they do not have a fixed set of strategies at all. Instead, the "consistency" support routine of a particular GiST operator class interprets the strategy numbers however it likes.
By the way, the amorderstrategy column
pg_am tells whether
the access method supports ordered scan. Zero means it doesn't; if it
does, amorderstrategy is the strategy
number that corresponds to the ordering operator. For example, B-tree
has amorderstrategy = 1, which is its
"less than" strategy number.
In short, an operator class must specify a set of operators that express each of these semantic ideas for the operator class's data type.