Details
-
New Feature
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
Description
It seems RPMs for 10.1.x come with only LZMA of all possible compression algorithms. It is suggested to build from source when other algorithms are needed (see https://mariadb.com/kb/en/mariadb/compression/).
On some systems (like RHEL) that we provide packages for some of these algorithms (like LZ4) are available as packages. I think it makes sense (maybe only for Enterprise binaries?) to build with them added and then add dependencies for the related packages.
-
But we cannot add new dependencies to rpm packages after GA. And we should not introduce new file formats lightly. If we add a compression library to our distributed packages, there will be a significant additional cost for removing the code later. Users who enabled an algorithm would have to execute additional steps on an upgrade to a later version where we might want to remove that form of compression. And we would have to provide an upgrade tool for converting affected files. To save us from such trouble, we should run some benchmarks beforehand and determine which library provides the best ratio between CPU usage and compression savings.
Attachments
Issue Links
- blocks
-
MDEV-20255 InnoDB LZ4 and LZMA compression algorithms aren't available on Debian 9
- Closed
-
MDEV-21877 Enable snappy compression by default for InnoDB page compression
- Open
-
MDEV-22895 Implement server support for making compression library dependencies optional
- Closed
- is blocked by
-
MDEV-22310 Support zstd Compression algorithm for IO
- Open
-
MDEV-26029 Sparse files are inefficient on thinly provisioned storage
- Closed
- relates to
-
MDEV-8139 Fix scrubbing
- Closed
-
MDEV-11916 Page compression - use smaller writes, avoid trimming/zeroing rest of the page if possible
- Open
-
MDEV-12933 sort out the compression library chaos
- Closed
-
MDEV-15528 Avoid writing freed InnoDB pages
- Closed
-
MDEV-22839 ROW_FORMAT=COMPRESSED vs PAGE_COMPRESSION=1 - size comparison
- Open