FTSはLIKEをサポートしていません
以前に受け入れられた答えは正しくありませんでした。全文索引を使用した全文検索はありません LIKEの場合 演算子はまったくありませんが、独自の演算子があり、任意の文字列に対しては機能しません。 単語で動作します 辞書とステミングに基づいています。 します 単語のプレフィックス一致をサポート 、ただしLIKEではありません 演算子：
- GINインデックス付きTSVECTOR列から部分一致を取得
LIKEのトリグラムインデックス
追加モジュールpg_trgmをインストールします これは、すべてのLIKEをサポートするGINおよびGiSTトリグラムインデックスの演算子クラスを提供します およびILIKE パターン 、左に固定されているものだけではありません：
インデックスの例：
CREATE INDEX tbl_col_gin_trgm_idx ON tbl USING gin (col gin_trgm_ops);または：
CREATE INDEX tbl_col_gist_trgm_idx ON tbl USING gist (col gist_trgm_ops);- GiSTとGINインデックスの違い
クエリの例：
SELECT * FROM tbl WHERE col LIKE '%foo%'; -- leading wildcard
SELECT * FROM tbl WHERE col ILIKE '%foo%'; -- works case insensitively as wellトライグラム？短い文字列はどうですか？
3文字未満の単語 インデックス付きの値でも機能します。マニュアル：
文字列に含まれるトライグラムのセットを決定するとき、各単語には接頭辞2つのスペースと接頭辞1つのスペースがあると見なされます。
そして、3文字未満の検索パターン？マニュアル：
両方の
LIKE正規表現検索では、抽出可能なトライグラムのないパターンは完全なインデックススキャンに縮退することに注意してください。
つまり、インデックス/ビットマップインデックススキャンは引き続き機能し（プリペアドステートメントのクエリプランは機能しません）、パフォーマンスが向上することはありません。 1文字または2文字の文字列はほとんど選択的ではなく（基になるテーブルの数パーセント以上が一致する）、全表スキャンの方が高速であるため、インデックスのサポートによって最初からパフォーマンスが向上しないため、通常は大きな損失はありません。
> text_pattern_ops プレフィックスマッチング用
左アンカーの場合 パターン（先頭のワイルドカードなし）は、btreeインデックスに適した演算子クラスで最適になります：text_pattern_ops またはvarchar_pattern_ops 。標準のPostgresの両方の組み込み機能であり、追加のモジュールは必要ありません。パフォーマンスは似ていますが、インデックスははるかに小さくなっています。
インデックスの例：
CREATE INDEX tbl_col_text_pattern_ops_idx ON tbl(col text_pattern_ops);クエリの例：
SELECT * FROM tbl WHERE col LIKE 'foo%'; -- no leading wildcardまたは 、'C'を使用してデータベースを実行する必要がある場合 ロケール（事実上いいえ ロケール）、とにかくすべてがバイト順序に従ってソートされ、デフォルトの演算子クラスを持つプレーンなbtreeインデックスがその役割を果たします。
dba.SEのこれらの関連する回答の詳細、説明、例、およびリンク：
- PostgreSQLのLIKE、SIMILAR TO、または正規表現とのパターンマッチング
- LIKEはどのように実装されますか？
- PostgreSQLで類似した文字列をすばやく見つける