performance - PostgreSQL では、別のテーブルではなく、同じテーブルに TEXT 列を含める方が高速ですか?

Question

どの設計が PostgreSQL でより高速に実行されると思いますか?

1. varchar などの 15 列のテーブルを作成しますが、すべての TEXT 列を別のテーブルに配置し、このテーブルに fkey リンクを戻します。そして、ID が「4」のレコードを検索し、結合されたテーブルの TEXT 列からのものを含め、すべての行を引き戻すとします。テーブルに 500,000 行あるとします。

2. varchar などの 15 列のテーブルを作成し、同じテーブルに TEXT 列を含めます。もう一度、上記と同じことを想像してください。レコード ID 4 を取得して完全なレコードを取得すると、テーブルには 500,000 行あります。

つまり、ほとんどのデータベースでは、私が理解しているように、これらの TEXT 列がどのように機能するかの物理層に降りると、実際には各行のテーブル列に小さな ID が保持され、その ID は別のものに移動します。データベース内の排他的なページ ブロック (またはその他の命名法)。したがって、私には、fkey結合のオーバーヘッドが不要であり、TEXT列が実際には特定のテーブルのその列の整数スペース以上を占有していないため、オプションBの方が高速に実行されるように思えます-その整数は、データベース内の別のページブロックへのキーです。

Answer 1

PostgreSQLは、他のDBMSと同じようにTEXT列を処理しません。

彼らのドキュメントから：

ヒント：ブランクパッドタイプを使用する場合のストレージサイズの増加と、長さに制約のあるカラムに保存する場合の長さをチェックするための数サイクルの追加を除いて、これら3つのタイプの間にパフォーマンスの違いはありません。character（n）は、他のいくつかのデータベースシステムではパフォーマンス上の利点がありますが、PostgreSQLではそのような利点はありません。ほとんどの場合、代わりにテキストまたは文字の変化を使用する必要があります。

マニュアルをチェックしてください

Answer 2

（B）は、質問自体に記載されている理由から正しいです。