データベースのパフォーマンスチューニングと聞くと、誰もが「速くする」ことを思い浮かべます。しかしJacob Jackson氏は逆に、「意図的に激遅にする」ことに挑戦したブログ記事「Making Postgres 42,000x slower because I am unemployed」を公開して注目を集めています。
同氏は、PostgreSQLの設定ファイルpostgresql.confを変更することで、TPSを7082からわずか0.17まで落とす(なんと42,000倍遅く)ことに成功しています。
実験は、Postgres 19devel、ベンチマークは「BenchBase TPC-C(データベースの性能評価に使われるベンチマークツールと、その中で使われる代表的なワークロード)」を用い、Ryzen 7950x + 32GB RAM + SSDを搭載したLinuxマシン上で行われました。
遅くするテクニック大全
同氏は以下のようなさまざまな方法でPostgreSQLを遅くすることに成功しています。
-
キャッシュ削減：
shared_buffersを極小（8MB→2MB）に設定し、ディスクI/Oを強制 -
Autovacuum過剰化：1件の挿入でvacuumが走るようにし、常にバックグラウンド作業を実行
-
ログ生成と統計収集の強化：無駄なログを大量に生成、統計情報更新で性能を削る
-
WAL設定の過剰化：書き込み遅延・チェックポイント頻度の過剰強化でI/Oを悪化
-
インデックス無効化：
random_page_cost等の値を極端化してクエリプランからインデックス利用を除外 -
I/Oスレッド制限：Postgres 18以降の
io_method=workerとio_workers=1でI/Oを1スレッドに制限
shared_buffers = 8MB autovacuum_vacuum_insert_threshold = 1 autovacuum_vacuum_threshold = 0 autovacuum_vacuum_scale_factor = 0 autovacuum_vacuum_max_threshold = 1 autovacuum_naptime = 1 vacuum_cost_limit = 10000 vacuum_cost_page_dirty = 0 vacuum_cost_page_hit = 0 vacuum_cost_page_miss = 0 autovacuum_analyze_threshold = 0 autovacuum_analyze_scale_factor = 0 maintenance_work_mem = 128kB log_autovacuum_min_duration = 0 logging_collector = on log_destination = stderr,jsonlog wal_writer_flush_after = 0 wal_writer_delay = 1 min_wal_size = 32MB max_wal_size = 32MB checkpoint_timeout = 30 checkpoint_flush_after = 1 wal_sync_method = open_datasync wal_level = logical wal_log_hints = on summarize_wal = on track_wal_io_timing = on checkpoint_completion_target = 0 random_page_cost = 1e300 cpu_index_tuple_cost = 1e300 io_method = worker io_workers = 1
この結果、初期状態は7082 TPSだったのに対し、約0.17 TPSと42,000倍遅くなるチューニングに成功しています。
まとめ
同氏は失業中で暇だったからやったと動機を説明していますが、PostgresのようなDBでは、設定次第で性能が劇的に変わることを可視化できる興味深い実験だといえそうです。
Hacker Newsでもこの記事に関する議論が行われており、「ここまで遅くできるとは思わなかった」という驚きの声や、PostgreSQLの柔軟性と堅牢性に感心するコメントが寄せられています。また、実験の再現性が高く、設定ファイルが公開されている点も好評です。
