maria-developers team mailing list archive

[陈福荣 <vinchen13@xxxxxxxxx>]

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@xxxxxxxxx>:

> 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@xxxxxxxxxxx>
> 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@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~maria-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
>
> --
> Mark Callaghan
> mdcallag@xxxxxxxxx
>