PostgreSQLデータによって消費されるディスク容量の削減

通常、データ構造とテーブルをコンパイルするとき、誰も列の順序を気にしません。 実際、ポイントは何ですか？ 必要に応じて、SELECTの列の順序を変更できますが、何を心配する必要がありますか？ そのため、列の順序がテーブルのサイズに大きく影響する可能性があるため、心配する必要があります。 はい、データが同じであっても、テーブルのサイズは列の順序に依存する場合があります。

この理由は何ですか？ CPUデータのアライメントなどがあり、データ構造の低レベルのサイズはそれに依存します。 列の順序を意識的に選択することで、データサイズを最適化できます。 信じられない？ 試してみましょう：

test=# CREATE TABLE t_test ( i1 int, i2 int, i3 int, v1 varchar(100), v2 varchar(100), v3 varchar(100) ); CREATE TABLE 

この例には6つの列があります。 3つの整数列と3つのvarchar列（次々）。 このテーブルに1,000万行を追加します。

 test=# INSERT INTO t_test SELECT 10, 20, 30, 'abcd', 'abcd', 'abcd' FROM generate_series(1, 10000000); INSERT 0 10000000 

テーブルの合計サイズは574 MBです。

 test=# SELECT pg_size_pretty(pg_relation_size('t_test')); pg_size_pretty ---------------- 574 MB (1 row) 

これらの列の場所を変更してみましょう。 次の例では、varchar列の後に整数列が続きます。 これは3回繰り返されます。

 test=# CREATE TABLE t_test ( v1 varchar(100), i1 int, v2 varchar(100), i2 int, v3 varchar(100), i3 int ); CREATE TABLE 

次に、1000万行を追加します...

 test=# INSERT INTO t_test SELECT 'abcd', 10, 'abcd', 20, 'abcd', 30 FROM generate_series(1, 10000000); INSERT 0 10000000 

...そしてテーブルは大幅に増加します：

 test=# SELECT pg_size_pretty(pg_relation_size('t_test')); pg_size_pretty ---------------- 651 MB (1 row) 

テーブル内のデータは変更されていません-この効果を示すために特別に選択されただけです。 「abcd」ではなく「abc」と書いた場合、サイズの違いは見られませんが、4文字の文字列は小さなバッファーに収まりません。

おわりに

この実験から導き出せる重要な結論は、同じデータ型を隣同士に詰めることは間違いなく意味があるということです。 さらに、テーブルの先頭に整数列をパックすることが理にかなっていることがわかりました。 多くの場合、データ構造がそうでない場合よりもわずかに小さいため、これによりパフォーマンスが数パーセント向上することがあります。

翻訳者から：

投稿者：Hans-JürgenSchönig。 オリジナルはこちらから入手できます 。