いくつかの問題が目立ちます：
まず、現在のバージョンのPostgresにアップグレードすることを検討してください 。これを書いている時点では、9.6ページまたは10ページ（現在はベータ版）です。 Pg 9.4以降、GINインデックス、追加モジュールpg_trgm、および一般的なビッグデータに複数の改善が加えられました。
次に、もっと多くの RAM が必要です 、特に高い work_mem 設定。 EXPLAINのこの行からわかります 出力：
Heap Blocks: exact=7625 lossy=223807
「不可逆」 ビットマップヒープスキャンの詳細 （特定の番号を使用して）work_memが劇的に不足していることを示します 。 Postgresは、行ポインタではなくビットマップインデックススキャンでブロックアドレスのみを収集します。これは、work_memが低いほど高速になると予想されるためです。 設定（RAMに正確なアドレスを保持することはできません）。次のビットマップヒープスキャンでは、さらに多くの非修飾行をフィルタリングする必要があります。 こちらです。この関連する回答には詳細があります：
ただし、work_memは設定しないでください あまりにも 全体の状況を考慮せずに高い：
インデックスやテーブルの肥大化、またはより多くの構成のボトルネックなど、他の問題が発生する可能性があります。ただし、これら2つの項目だけを修正すると、クエリは多くになるはずです。 すでに速くなっています。
また、この例では本当にすべての40k行を取得する必要がありますか？小さなLIMITを追加することをお勧めします クエリに追加して「最近傍」検索にします。この場合、結局のところ、GiSTインデックスの方が適しています。それ GiSTインデックスを使用すると高速になるはずです。例：