この理由は何ですか? 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。 オリジナルはこちらから入手できます 。