1

テーブルの列にGiSTpg_trgmインデックスを設定しました。namefiles

準備されたステートメントの簡略化されたクエリは次のようになります。

SELECT * FROM files WHERE name LIKE $1;

$1パラメータは + ユーザー クエリ + で構成され%ます%。入力も空の文字列になる可能性があるため、%%.

「空」LIKE( %%) はパフォーマンスの低下につながりますか? その場合、新しいクエリを作成する必要がありますか、それとも問題ではありませんか?

4

1 に答える 1

2

Postgres 9.2 以降は、通常、この状態を認識するのに十分スマートです。

WHERE name LIKE '%%'

選択的ではなく、準備されたステートメントであっても、GiST インデックスを無視してシーケンシャル スキャンに頼ります。ただし、役に立たない状態に対して少額の代償を払います。

Postgres 9.1 以前では、特別な場合に別のクエリを作成していました。

バージョン9.1、9.2、および9.3のマニュアルのステートメントについては、 「注」セクションを比較してください。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 は、負荷などによって大きく異なります。単一の実行は信頼できない場合があります。環境でより適切にテストし、各ステートメントを数回実行して、キャッシュを飽和させ、ノイズを排除します。

于 2013-09-25T17:07:12.140 に答える