Tweet
My main fundamental issue is as follows:
The B-Tree and its variants (e.g., B+-Tree) are what most databases (including, but not limited to, Postgresql/MariaDB/Mysql) use for ordered, fixed-sized data (e.g., indexes, tables). They have great theoretical and practical performance when it comes to random r/w accesses (and sequential accesses, too ...)
Well, random-access writes conflict from a performance standpoint with how COW is implemented ... Some special accommodation is needed for such files. Now I should add here that BTRFS uses (AFAICT) Btrees itself for its on-disk metadata. But ... this doesn't mean it's efficient for regular files that update Btrees randomly.
The B-Tree and its variants (e.g., B+-Tree) are what most databases (including, but not limited to, Postgresql/MariaDB/Mysql) use for ordered, fixed-sized data (e.g., indexes, tables). They have great theoretical and practical performance when it comes to random r/w accesses (and sequential accesses, too ...)
Well, random-access writes conflict from a performance standpoint with how COW is implemented ... Some special accommodation is needed for such files. Now I should add here that BTRFS uses (AFAICT) Btrees itself for its on-disk metadata. But ... this doesn't mean it's efficient for regular files that update Btrees randomly.
Comment