これは機能します:
SELECT * FROM aTable WHERE junk='foo bar';
これは永遠にハングします:
SELECT * FROM aTable WHERE junk~'foo bar';
これは永遠にハングします:
SELECT * FROM aTable WHERE junk~'foo b.*';
何が問題なのですか?
編集:SQLクエリが送信されても応答がないという状況はありますか?たとえば、無限ループ、不正な構文など。
これは機能します:
SELECT * FROM aTable WHERE junk='foo bar';
これは永遠にハングします:
SELECT * FROM aTable WHERE junk~'foo bar';
これは永遠にハングします:
SELECT * FROM aTable WHERE junk~'foo b.*';
何が問題なのですか?
編集:SQLクエリが送信されても応答がないという状況はありますか?たとえば、無限ループ、不正な構文など。
何も悪いことはありません。
正規表現を使用する2つのクエリはどちらも、インデックスを使用して最適化することはできません。
その結果、フルスキャンが実行されるため、時間がかかります。
3つすべてが正しいですが、を使用してクエリプランを調べるEXPLAIN
と、プランが大きく異なることがわかります。
このSQLFiddleを参照してください-実行時間が異なることに注意してください。「ビュー実行プラン」を使用してクエリプランを調べます。
あなたの場合、=
はおそらく単一の値に対してb-treeインデックスルックアップを使用していますが、これは非常に高速であるはずですが、~
バージョンはおそらくシーケンシャルスキャンを実行しています-正規表現を試す必要があるため、CPUにかなりのコストがかかりますすべての行に対して。
便利なことに、私は別の投稿に答えてこれについて書いたところです。この回答を参照してください。これは、適切に作成されたインデックスLIKE
をSIMILAR TO
使用してプレフィックスを一致させることができますが、使用することは~
できません。
CREATE INDEX atable_junk_txt_idx ON aTable(junk text_pattern_ops)
のようにインデックスを作成してみてくださいLIKE 'foo b%'
。
インデックスを追加すると、挿入、更新、削除の速度が低下するため、必要のないインデックスを作成しないでください。
Pgwikiのexplainの使用を参照してください。