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