10カラム、20カラム…と、100カラムのテーブルまで、カラムを10ずつ増やしながら10テーブルを用意。データは、主キーとなるIDにのみシリアル値を設定したレコードを、各テーブルに100万件だけ用意してみた。さっそく、それぞれにSELECT文を投げてみる。

この結果を見る限り、カラム数による影響はなし。

はて、では何が原因で劣化を感じたのだろうか。カラム数に比例して増えるのは、データである。そこで今度は、10カラムのテーブルで、1カラムずつデータを挿入していったときの性能比較。対象レコード数は100万件。各テーブルにSELECT文を投げてみる。

データ量が増えるにしたがって検索性能が落ちている。落ちているとは言っても、100万レコードに値を入れて、それで100ミリ秒遅くなっている程度だけど。

ということで、カラム数が増えることで性能が落ちるのではなく、カラムが多いテーブルではデータ量も多くなるので性能が落ちる、というのが本当のところか。カラム数が1000とかになったら激しく性能劣化する可能性もあるから、断定はできないけど、100カラム程度であれば、カラム数の影響はないようだ。

データ量の増加にともなって検索速度が落ちる点についても、ちゃんと VACUUM FULL や REINDEX していくことで、影響は最小限に抑えられる。これらを計画的に行うような設計にしておけば、数百万件レベルなら臆することでもない。

ただし。

カラム数が膨大なテーブルは、保守の面から考えると、決して便利とは言えない。設計はラクかもしれないけど、個人的にオススメはできない。

自分が設計するときに、テーブルのカラム数が40～50を大きく超える場合は、派生させたテーブルを作って分割管理することを検討する。結合のコストがかかるとは言うものの、実はそういった横長テーブルのうち、よくSELECTされるのは30程度だったりする。それならば、結合コストを犠牲することも、やぶさかではないと思う。ま、でも基本は正規化ですけどね！

以上、お疲れさまでした。