PostgreSQLには、Bツリー、ハッシュ、GiST、Gin、およびSP-GiSTのいくつかのタイプのインデックスがあります。明らかに、それらのそれぞれが特定のニーズをカバーしています。たとえば、PostgreSQLのドキュメントにはGINインデックスについて記載されています：
したがって、GINインデックスを使用して、配列やhstoreなどの要素にインデックスを付けることができます。
ただし、今回は、GINインデックスで使用できるより多くの種類の演算子を提供するcontribモジュールの1つであるpg_trgmについて説明します。
このモジュールは、類似点を見つけるために使用できるように、テキスト文字列のトライグラムを作成します。これにより、検索パターンの先頭に'％'ワイルドカードが見つかった場合でも、gin_trgm_ops演算子クラスを使用するGINのようなインデックスをLIKE検索で使用できます（例：LIKE名'％jaime％'）。
>このように使用できるインデックスを作成するには、次のようにインデックスを作成する必要があります。
CREATE INDEX idx_gin ON table USING GIN (campo_texto gin_trgm_ops);
このようなインデックスを使用すると、クエリが10秒以上から数ミリ秒に減少するのを確認しました。ただし、これらのインデックスを急いで作成する前に、発生している問題について考えてみましょう。
次のクエリ「selectshow_trgm（'JaimeCasanova'）;」について考えてみます。これは、テキスト文字列のトライグラム、この場合は15トライグラムを示しています。したがって、このタイプのインデックスが大幅に大きくなり、テキスト文字列が大きくなるほど、インデックスが大きくなることを想像するのは難しくありません（トライグラムが増えるため）。もう1つの明らかな結論は、このタイプのインデックスの維持にはコストがかかる可能性があることです。実際、特に同じテーブルにこれらのインデックスが複数ある場合は、INSERTとUPDATEのパフォーマンスに大きな影響を与え、この問題を少し減らすためにfastupdateと呼ばれる手法を使用します。保留中の順序付けられていないリストを維持することで構成されるが発明されました。したがって、メインインデックスに挿入する代わりに、INSERTとUPDATEは、VACUUMが発生するまで、または保留リストがwork_memより大きくなるまで、この追加の構造に挿入します。欠点は次のとおりです。1）インデックスを読み取るには、この追加の構造も読み取る必要があります。これは、クエリのパフォーマンスに影響を与える可能性があります。 2）INSERTまたはUPDATEにより、バックログが大きくなりすぎる可能性があるため、バックログの処理が開始され、そのINSERTまたはUPDATEと、そのテーブルで同時に発生する他のすべての操作に影響します。
結論は; GINインデックスとpg_trgmモジュールは、一部のクエリのパフォーマンスを大幅に向上させることができますが、両刃の剣である可能性があるため、悪用しないでください。