amstrategies 列は、データ型をまたがる比較処理を標準化するためのものです。 たとえば B-tree の場合、キーが小さい方から大きい方へ厳密に並んでいなければなりません。 PostgreSQL ではユーザが演算子を定義できますので、 PostgreSQL は演算子（たとえば > や <）の名前を見つけ、その演算子がどのような比較を 行なうのかは解りません。 実際、アクセスメソッドによってはまったく順序性を規定しないものもあります。たとえば R-tree は四角形に閉じた関係を表しますが、そのハッシュデータの構造はハッシュ関数の値によってビット毎の類似性を表しているだけです。 PostgreSQL は、ある一貫性を持った方法で、クエリ内の条件を取り出し、演算子を探し、インデックスが使用可能かどうかを決定する必要があります。ということは、 PostgreSQL は、たとえば <= や > 演算子は B-tree を区切るということを知っている必要があることになります。 PostgreSQL はストラテジを用いて、演算子とインデックスをスキャンする方法との間のこれらの関係を、表現しています。
新しいストラテジ集合の定義は本節の範囲ではありませんが、 新しい B-tree 演算子クラスを追加するために必要ですので、ここで B-tree ストラテジがどのように動作するかを説明することにします。 pg_am テーブルにおいて amstrategies 列は、このアクセスメソッド用に定義されたストラテジの数を示します。 B-tree では、 この数は 5 です。これらのストラテジの意味を Table 17-2 に示します。
考え方としては、上述のストラテジに対応する演算子を、pg_amop リレーション（後述）に追加する 必要があるということです。 B-tree をどう分割するか、選択性をどう計算するかなどを見つけるために、アクセスメソッドのコードは、データ型にかかわらずこれらのストラテジ番号を使用することができます。演算子を追加するための具体的な方法についてはまだ気にかけることはありません。 B-tree が操作できる int2, int4, oid やその他のデータ型には、これらの演算子が必要であるということを理解できればよいのです。