データベースの列のサイズによってクエリが遅くなることがありますか？

Question

私は、HTMLコンテンツを含む表を持ち、他の列よりも相対的に大きい表を持っています。

大きなサイズの列を使用すると、このテーブルのクエリが遅くなることがありますか？ この大きなフィールドを別のテーブルに配置する必要がありますか？

Answer 1

を選択する際に

時々、列の順序は、あなたがそれについては本当に心配している場合は、理由の行が保管されている方法の問題で、それがページングされませんので、最後の列として保存することができますTOASTテクニックはこれを処理しなければなりません。与えられたサイズの後、ストレージは_toastテーブルに透過的に設定され、クエリーが遅くなるのを避けるためにいくつかの内部処理が行われます。

もちろん、常にコンテンツ全体を取得すると、検索に時間がかかります。また、この列が使用されていないこの表の要求は、この列のサイズに影響されないことも明らかです。

Answer 2

データベースが大きければ大きいほどクエリは遅くなります。常に。

Answer 3

大きなカラムを使用すると、カラム自体をキャッシュするとより多くの領域が必要になるため、ディスクI/Oが増える可能性があります。ただし、これらを別の表に置くことは、この問題を軽減する可能性は低いです（下記の問題以外）。実際のHTMLデータが明示的に必要ない場合は、それを選択しないでください。他の列

Answer 4

これを分割する必要があるかどうかを調べるためにPostgresが内部的にどのように物事を保存しているかを調べる必要がありますが、非常に大きなフィールドは、ディスク上のデータを分割して時間を増やすそれにアクセスするのにかかる。

さらに、1レコードの10000バイトのデータを100バイト戻すことは明らかに遅くなりますが、記録するほど遅くなります。 SELECT *を実行している場合、通常HTMLを必要としない場合は、明らかに問題があります。

また、noSQLデータベースにHTML情報を挿入することもできます。この種の文書情報は、彼らが優れているものです。何らかの情報のために実在のデータベースと他の情報のためのnoSQLデータベースの両方を使うことはできません。