Hi mark There are 3 bits reserved for compressed algorithm in Compressed Record. It would be always 0 at present, means zlib. It can be easy to support other compression algorithm in the future. Compressed Record Record Header: 1 Byte 7 Bit: Always 1, mean compressed; 4-6 Bit: Reversed, compressed algorithm Now it is always 0, means zlib. It maybe support other compression algorithm in the future. 0-3 Bit: Bytes of "Record Original Length" Record Original Length: 1-4 Bytes Compressed Buf: 2016-10-21 7:32 GMT+08:00 MARK CALLAGHAN <mdcallag@gmail.com>:
How easy will it be for this to use a lower latency compression algorithm like lz4, Snappy or zstandard?
On Thu, Oct 20, 2016 at 2:52 PM, Daniel Black <daniel.black@au1.ibm.com> wrote:
+#define BINLOG_COMPRESSED_HEADER_LEN 1 +#define BINLOG_COMPRESSED_ORIGINAL_LENGTH_MAX_BYTES 4 +/** + Compressed Record + Record Header: 1 Byte + 0 Bit: Always 1, mean compressed; + 1-3 Bit: Reversed, compressed algorithm??Always 0, means zlib
Good to see this progressed from the old MySQL bug I saw originally.
I'm a bit late into this however I suggest we can use a better algorithm than zlib. There are a significant number of algorithms that may have better compression at similar speed faster like brotli, zstd, snappy.
https://quixdb.github.io/squash-benchmark/#results-table
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
-- Mark Callaghan mdcallag@gmail.com