私はmanjaro KDEを開発しており、/パーティション全体（もちろん/ boot / efiパーティションを除く）はbtrfsファイルシステムでフォーマットされており、書き込み時のコピー機能はまだデフォルトです。私はPostgresをインストールするためにArch wikiをフォローしていましたが、私がよく理解していないことがわかりました。
#https://wiki.archlinux.org/title/PostgreSQL
Warning:
If the database resides on a Btrfs file system, you should consider disabling Copy-on-Write for the directory before creating any database.
Googleで検索してみましたが、私が見たのはCOWがデータベースのパフォーマンスを低下させると言っているようです。しかし、どのようにこれが起こりましたか？ COWはI/O待ち時間を減らすとされていませんか？
PS英語は私の母国語ではありません。いくつかの構文エラーがある可能性があります。許してください。
頑張ってください。
ベストアンサー1
リンクをクリックするとここ>ここ>ついに来ました。次の単語が表示されることがあります。
Btrfsは、Ohad Rodehが提案したリダイレクトベースのBツリー更新方法に基づいており、コードを理解しやすくするため、Btrfsは「書き込み時のコピー」ではなく「書き込み時のリダイレクト」を実行すると主張しています。その考え方を利用しています。
その結果、記録中にコピーは別の場所に新しいデータを書き、リダイレクトを残します。これにより、ディスクにファイルの断片化が発生する可能性があります。この答えにはこれについての議論があります。https://unix.stackexchange.com/a/395013/20140
これをpostgresql（ほとんどの最新のDBMSと同様）の動作と組み合わせると、結果はあまり望ましくありません。 postgresqlは非常に大きなファイルに「ランダム」書き込みをたくさん実行するためです。 btrfsはこれらのファイルを真剣に断片化する可能性があります。
さらに悪いことに、postgresqlはすでに非常に最適化されているということです。最小限のディスクスキャンを生成するために読み取り計画を試みます。また、行が書き込まれるときに収集されたテーブルデータをディスク上の同じ場所に保持しようとします。ファイルがディスク全体に分散されていると、読み取りデータをまとめて収集する機能が妨げられ、結果として速度が遅くなります。
postgresqlには次のプロセスがあります。真空。 Vacuumの仕事の1つは、同じテーブルからデータを大まかに収集することです。記録中にコピーをオンにすると、このプロセスは実際には正反対の効果を持ち、データがディスク全体に広く分散する可能性があります。
また、非常に高速なSSDドライブを使用すると、断片化のコストはやや削減されますが、まだ存在することを指摘したいと思います。
磁気貯蔵コストは膨大です。ディスクは小さな動きで一度に多くのMBを読み取ることができます。しかし、データが断片化されると、ディスクヘッドは新しい場所を「見つける」必要があります。これは（計算的に）長い時間がかかります。