5 ms·
Yes, but on the other hand, my toast relation now needs (e.g.) 4x the amount of blocks it would have had when compression was enabled. So we have a net 0 storag
by mattashii 5y ago
Yes, but on the other hand, my toast relation now needs (e.g.) 4x the amount of blocks it would have had when compression was enabled. So we have a net 0 storage savings, except that we now need to request 4x as many pages from the OS to get the full toast data, those pages taking up 4x as much space in Postgres' shared buffers, also evicting 4x as many pages from the buffers as it would have otherwise.
Unless your read operations to the file system are somehow very cheap, I don't think disabling toast compression is a good idea.
- throwdbaaway 5y agoI see your point. Perhaps the best way is to use TOAST compression for wide field values, and then rely on ZFS filesystem compression for others? For some context, in MySQL, both the table-level compression and page-level compression are problematic, while ZFS has served me well, thus I have a lot more faith in it.
- ComputerGuru 5y ago> a Perhaps the best way is to use TOAST compression for wide field values You don’t have to do anything. Toast compression is enabled for compatible types by default but never kicks in until a cell hits 2K bytes in size (by default).
- magicalhippo 5y agoLZ4 is quite fast to bail on data it can't compress, so why not just have LZ4 enabled on both?