データベースのパフォーマンスチューニングと聞くと、誰もが「速くする」ことを思い浮かべます。しかしJacob Jackson氏は逆に、「意図的に激遅にする」ことに挑戦したブログ記事「Making Postgres 42,000x slower because I am unemployed」を公開して注目を集めています。同氏は、PostgreSQLの設定ファイルpostgresql.confを変更することで、TPSを7082からわずか0.17まで落とす(なんと42,000倍遅く)ことに成功しています。TPS(Transactions Per Second)は1秒あたりのトランザクション数を意味します。データベースやシステムの処理性能を測る指標として使われます。実験は、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 = 8MBautovacuum_vacuum_insert_threshold = 1autovacuum_vacuum_threshold = 0autovacuum_vacuum_scale_factor = 0autovacuum_vacuum_max_threshold = 1autovacuum_naptime = 1vacuum_cost_limit = 10000vacuum_cost_page_dirty = 0vacuum_cost_page_hit = 0vacuum_cost_page_miss = 0autovacuum_analyze_threshold = 0autovacuum_analyze_scale_factor = 0maintenance_work_mem = 128kBlog_autovacuum_min_duration = 0logging_collector = onlog_destination = stderr,jsonlogwal_writer_flush_after = 0wal_writer_delay = 1min_wal_size = 32MBmax_wal_size = 32MBcheckpoint_timeout = 30checkpoint_flush_after = 1wal_sync_method = open_datasyncwal_level = logicalwal_log_hints = onsummarize_wal = ontrack_wal_io_timing = oncheckpoint_completion_target = 0random_page_cost = 1e300cpu_index_tuple_cost = 1e300io_method = workerio_workers = 1この結果、初期状態は7082 TPSだったのに対し、約0.17 TPSと42,000倍遅くなるチューニングに成功しています。まとめ同氏は失業中で暇だったからやったと動機を説明していますが、PostgresのようなDBでは、設定次第で性能が劇的に変わることを可視化できる興味深い実験だといえそうです。Hacker Newsでもこの記事に関する議論が行われており、「ここまで遅くできるとは思わなかった」という驚きの声や、PostgreSQLの柔軟性と堅牢性に感心するコメントが寄せられています。また、実験の再現性が高く、設定ファイルが公開されている点も好評です。