PostgreSQL13 1600カラムを1000万件いれてみた

やりたいこと

カラム数の多さがどれだけパフォーマンスに影響するのかを確かめたいと思いやってみました。
そこで、PostgreSQLのMAXである1600カラムを作成し、データを1000万件入れました。

##結論から
かなりの差がでます。
select count(*)を行うと致命的
他にもデータ自体を検索してしまうとカラム数が多い場合、実行時間がまともに動作しないレベル。
カラム数はあんまり多くしないようにしましょう。
もちろん、インデックスは使いましょう。

前提

PostgreSQLで使ったのはAWS RDS(t3.micro)です。
以下の2つのテーブルを比べることでパフォーマンスを比較します

■testテーブル
　・カラム数は、以下の3つ　
　　1.character varying(256)
　　2.integer
　　3.timestamp with time zone
　・CSVでインポート。サイズは650MBほど
　・1000万件のデータがあります。
　・インデックスなし

■test_1600テーブル
　・カラム数は、以下の1600個
　　1.character varying(256)
　　2.timestamp with time zone
　　3.integerが1598カラムあります。
　・CSVでインポート。サイズは73GB・・(汗 でかい
　・1000万件のデータがあります。
　・インデックスなし

データ個数確認！

カラムが多いと実行時間が123倍かかるようです。

■testテーブルは1000万件確認
約4秒かかりました。

実行計画を見てみます

■test_1600テーブルも万件確認
約10分かかりました・・これはまずい

実行計画を見てみます
Excustion Timeが実行時間です。10分ほどかかってます。

##インデックスがない状態で1行取得してみる
存在しないデータを取得してみる
カラムが多いと実行時間が78倍かかるようです。

■testテーブル
約4秒

■test_1600テーブル
約314秒

##インデックスがある状態で存在する1行取得してみる

■testテーブル
インデックスはると、データ自体を使わないため、あんまりかわらないですね

約0.038ms

■test_1600テーブル
約0.245秒

##CPU使用率もスパイクしまくる
select count(*)と、インデックスなしでアクセスしたからだと思います。

##読み取り IOPS