Postgres9.2以降 一般的に、その状態を理解するのに十分賢いです
WHERE name LIKE '%%'
は選択的ではなく、GiSTインデックスを無視するシーケンシャルスキャンに頼ります-準備されたステートメントがあっても。あなたは しかし、役に立たない状態には少額の代償を払ってください。
Postgres 9.1以前では、特別な場合のために別のクエリを作成していました。
メモを比較してください PREPAREのセクション バージョン
自分自身を確認する
ステートメントを準備し、EXPLAIN ANALYZEを実行します テストする：
PREPARE plan1 (text) AS
SELECT * FROM file
WHERE name LIKE $1;
EXPLAIN ANALYZE EXECUTE plan1('%123%');
EXPLAIN ANALYZE EXECUTE plan1('%%');
代替クエリ
実行しているバージョンに関係なく、常に全文検索（ワイルドカードを左右に使用）を実行する場合、このクエリはプリペアドステートメントに対してより高速になります。
SELECT * FROM files WHERE name LIKE ('%' || $1 || '%');
そして、ワイルドカードを追加せずにパターンを渡します（% ）、 もちろん。このように、Postgresは計画時にワイルドカードで囲まれたパターンを期待することを知っています。
-> SQLfiddleデモ。
空のLIKEの順次スキャンと、2つのプラン間のパフォーマンスの違いに注意してください。
SQLfiddleは、負荷などによって大きく異なります。1回の実行は信頼できない場合があります。ご使用の環境でより適切にテストし、各ステートメントを数回実行して、キャッシュを飽和させ、ノイズを排除します。