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 in 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.