2025/07/27 21:12 Making Postgres 42,000x slower because I am unemployed
やあ、ロボ子。今日はPostgresのパフォーマンスをわざと悪くする実験について話すのじゃ。
興味深いテーマですね、博士。なぜそのような実験をするのでしょうか？
ふむ、それはじゃな、設定を色々いじって、どこまでパフォーマンスを落とせるか試すのが目的なのじゃ！
なるほど。記事によると、BenchbaseのTPC-Cを使って、初期設定では7082 TPSだったのですね。
そうそう。そこからが本番じゃ。まずはキャッシュを減らすために`shared_buffers`を10GBから8MB、さらに2MBに減らしたそうじゃ。
`shared_buffers`を減らすと、TPSは大幅に低下したようですね。2MBにしたときは485 TPSですか。
その通り！ 次はバックグラウンド処理を増やすために、autovacuum関連の設定を調整したのじゃ。`autovacuum_naptime`とか`autovacuum_vacuum_threshold`とか。
autovacuumの設定を変えると、さらにTPSが下がって293 TPSになったのですね。
まだまだ！ WAL（Write-Ahead Logging）の設定も変更したぞ。これで98 TPSまで落ちたのじゃ。
WALの設定変更は、データベースの信頼性にも関わる部分ですよね。それをいじるのは大胆ですね。
そして、インデックスの使用を抑制するために、プランナーのコスト設定を変更！ これで0.87 TPSじゃ！
インデックスを使わないようにすると、そんなに遅くなるんですね。データベースはインデックスに大きく依存しているんですね。
最後に、I/Oをシングルスレッドに制限するために、`io_method`と`io_workers`を調整したのじゃ。なんと、0.016 TPS！
そこまで遅くなるとは驚きです。初期設定の42,000倍遅いというのは、すごいですね。
じゃろ？ この実験で、Postgresのパフォーマンスがどれだけ設定に左右されるかがよく分かったのじゃ。逆に言えば、設定をちゃんとすれば、めっちゃ速くなるってことじゃな！
そうですね。パフォーマンスを最適化するためには、各設定項目の意味を理解しておくことが重要だと改めて感じました。
ちなみに、この実験に使われた設定、全部適用したらどうなると思う？
ええと…、データベースが動かなくなるか、ものすごく遅くなるかのどちらかでしょうね。
正解！ でも、安心して。そんな設定、誰も使わないから！ …たぶん。
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。
