検索文字列が長くなると、トライグラム検索が非常に遅くなります

Postgres 9.1データベースには、table1約150万行と1列のテーブルがありますlabel（この質問のために簡略化された名前）。

機能的なtrigram-indexがありますlower(unaccent(label))（インデックスでunaccent()使用できるように不変にされています）。

次のクエリは非常に高速です。

SELECT count(*) FROM table1
WHERE (lower(unaccent(label)) like lower(unaccent('%someword%')));
 count 
-------
     1
(1 row)

Time: 394,295 ms

ただし、次のクエリは遅くなります。

SELECT count(*) FROM table1
WHERE (lower(unaccent(label)) like lower(unaccent('%someword and some more%')));
 count 
-------
     1
(1 row)

Time: 1405,749 ms

また、検索がより厳密であっても、単語の追加はさらに遅くなります。

私は最初の単語のサブクエリを実行し、次に完全な検索文字列でクエリを実行する簡単なトリックを試しましたが、クエリプランナは（悲しいことに）私の陰謀を見ました：

EXPLAIN ANALYZE
SELECT * FROM (
   SELECT id, title, label from table1
   WHERE lower(unaccent(label)) like lower(unaccent('%someword%'))
   ) t1
WHERE lower(unaccent(label)) like lower(unaccent('%someword and some more%'));

テーブル1のビットマップヒープスキャン（コスト= 16216.01..16220.04行= 1幅= 212）（実際の時間= 1824.017..1824.019行= 1ループ= 1）
  Condの再チェック：（（lower（unaccent（（label）:: text））~~ '％someword％' :: text）AND（lower（unaccent（（label）:: text））~~ '％somewordなど％'：：テキスト））
  -> table1_label_hun_gin_trgmのビットマップインデックススキャン（cost = 0.00..16216.01 rows = 1 width = 0）（actual time = 1823.900..1823.900 rows = 1 loops = 1）
        インデックス条件：（（lower（unaccent（（label）:: text））~~ '％someword％' :: text）AND（lower（unaccent（（label）:: text））~~ '％somewordなど％'：：テキスト））
合計ランタイム：1824.064ミリ秒

私の究極の問題は、検索文字列が非常に長い文字列を送信するWebインターフェースに由来するため、非常に遅くなり、DOSベクトルを構成する可能性があることです。

だから私の質問は：

• クエリを高速化する方法は？
• より速くなるようにサブクエリに分割する方法はありますか？
• 後のバージョンのPostgresの方が良いのでしょうか？（私は9.4を試してみましたが、速くは見えません。それでも同じ効果です。後のバージョンでしょうか？）
• 別のインデックス作成戦略が必要な場合がありますか？

PostgreSQL 9.6には、pg_trgmの新しいバージョン1.2があり、これについてははるかに改善されます。少し手間をかけるだけで、この新しいバージョンをPostgreSQL 9.4で動作させることもできます（パッチを適用し、拡張モジュールを自分でコンパイルしてインストールする必要があります）。

最も古いバージョンでは、クエリ内の各トライグラムを検索し、それらの和集合を取得してからフィルターを適用します。新しいバージョンが行うことは、クエリで最もまれなトライグラムを選択し、そのトライグラムのみを検索し、残りを後でフィルタリングします。

これを行うための機械は9.1には存在しません。9.4では、その機械が追加されましたが、そのときpg_trgmはそれを利用するように適合されていませんでした。

悪意のある人が一般的なトライグラムのみを含むクエリを作成できるため、DOSの潜在的な問題が引き続き発生します。「％and％」、または「％a％」など

pg_trgm 1.2にアップグレードできない場合、プランナーをだます別の方法は次のとおりです。

WHERE (lower(unaccent(label)) like lower(unaccent('%someword%'))) 
AND   (lower(unaccent(label||'')) like 
      lower(unaccent('%someword and some more%')));

空の文字列を連結してラベルを付けることにより、プランナーをだまして、where句のその部分のインデックスを使用できないと考えさせます。したがって、％someword％だけでインデックスを使用し、それらの行だけにフィルターを適用します。

また、常に単語全体を検索する場合は、関数を使用して文字列を単語の配列にトークン化し、その配列を返す関数で通常の組み込みGINインデックス（pg_trgmではない）を使用できます。

クエリプランナーを詐欺する方法を見つけました。これは非常に単純なハックです。

SELECT *
FROM (
   select id, title, label
   from   table1
   where  lower(unaccent(label)) like lower(unaccent('%someword%'))
   ) t1
WHERE lower(lower(unaccent(label))) like lower(unaccent('%someword and more%'))

EXPLAIN 出力：

テーブル1のビットマップヒープスキャン（コスト= 6749.11..7332.71行= 1幅= 212）（実際の時間= 256.607..256.609行= 1ループ= 1）
  Condの再確認：（lower（unaccent（（label_hun）:: text））~~ '％someword％' :: text）
  フィルター：（lower（lower（unaccent（（label）:: text）））~~ '％someword and some more％' :: text）
  -> table1_label_hun_gin_trgmのビットマップインデックススキャン（cost = 0.00..6749.11 rows = 147 width = 0）（actual time = 256.499..256.499 rows = 1 loops = 1）
        インデックス条件：（lower（unaccent（（label）:: text））~~ '％someword％' :: text）
合計ランタイム：256.653ミリ秒

そのためlower(lower(unaccent(label)))、のインデックスがないため、順次スキャンが作成されるため、単純なフィルターに変換されます。さらに、単純なANDも同じことを行います。

SELECT id, title, label
FROM table1
WHERE lower(unaccent(label)) like lower(unaccent('%someword%'))
AND   lower(lower(unaccent(label))) like lower(unaccent('%someword and more%'))

もちろん、インデックススキャンで使用される切り抜き部分が非常に一般的である場合、これはうまく機能しない可能性があるヒューリスティックです。しかし、データベースでは、約10〜15文字を使用する場合、それほど多くの繰り返しはありません。

残りの2つの小さな質問があります。

• なぜpostgresはこのようなものが有益であると理解できないのでしょうか？
• postgresは0..256.499の時間範囲で何をしますか（出力の分析を参照）。