How does one ,by tunning a vanilla PostgreSQL (on a per instance or per database or per table basis) can get the same kind of advantages (and tradeoff) than in MySQL/MariaDB by switching from InnoDB to TokuDB ?
How does one ,by tunning a vanilla PostgreSQL (on a per instance or per database or per table basis) can get the same kind of advantages (and tradeoff) than in MySQL/MariaDB by switching from InnoDB to TokuDB ?
You can also mix-and-match. You could use PostgreSQL's regular storage engine for some tables, and TokuDB for some others.
The closest thing I know of to achieve something comparable with PG would be to use a data directory mounted on something with transparent filesystem-level compression (meaning, practically speaking, ZFS). This gives you the less-than-ideal choice of a not-mainline-linux filesystem (for your database's data directory, which is worth being nervous about) or running an OpenSolaris descendant, which is a big departure for plenty of people who have only ever run production dbs on Linux servers.
BTRFS has been in the stable kernel for over two years, so it might be worth checking out!
ZFS is the only filesystem it's reasonable to trust critical data on right now (I can't think of any other OSS self-validating Merkle trees that have been hammered in production for nearly a decade...), yet somehow some minor differences in Unicies trumps that.
I'm going to make a bold claim I know will stir the nest, but I feel confident in making given all the bad shit most filesystems miss: if you're not running your OSS RDBMS on ZFS right now, and you don't have compelling specialized needs to explain why not, you shouldn't be let near a production DB due to plain negligence and/or incompetence.