performance - search_data tsvectorを同じテーブルまたは外部テーブルに保存する必要がありますか？

Question

私はpostgresで全文検索を実装しています。

システム内のすべての投稿を検索したいと思います。投稿の全文索引は、投稿のタイトルと本文を組み合わせたものです。

これを達成する方法は2つあります。

1. 投稿テーブルにtsvector列を作成し、更新をトリガーします。
2. インデックスデータを含むpost_id列とtsvector列を使用して2番目のテーブル（posts_search）を作成します。
3. 単純なジンインデックスを作成します...（問題外ですが、私の現実の問題では、インデックス用に複数のテーブルのデータが必要です）

テーブル内の他の属性（など）で検索をフィルタリングする必要がある場合があることを考えると、パフォーマンスは向上しますdeleted_at is null。

tsvector列をデータと同じテーブル（副作用select *は最悪）または別のテーブル（副作用、結合が必要、インデックスフィルタリングが複雑）に保持する方が良いアプローチですか？

Answer 1

私の実験では、tsvector列の一般的なサイズは、1%このtsvectorがを使用して計算されたテキストフィールドのサイズとほぼ同じto_tsvector()です。

これを念頭に置いて、tsvector列を別のテーブルに格納すると、パフォーマンスが向上するはずです。たとえば、使用しない場合でもSELECT *（実際には使用しないでください）、元の単一テーブルのseqscanは、元のテキストを含むページをロードする必要があります。tsvectorフィールドを別のテーブルにオフロードすると、ページのロードが100倍速くなります。

言い換えれば、tsvectorフィールドを別のテーブルにオフロードする2番目のソリューションを優先します。または、代わりに、投稿（元のテキスト）をテーブル階層のより深いところにオフロードします（ただし、ほぼ同じことだと思います）。

全文検索が機能するために、元のテキストは必要ないことに注意してください。データベースに保存したり、高度に圧縮された形式で保存したりすることもできません（SQLルーチンから簡単にアクセスできるとは限りません）。元のテキストに基づいてtsvectorを作成したり、変更されたときに更新したりできる限り、機能します。