Hi, Compressed binlogs are something that have interested me for some time[1] so it is nice to see patches which provide this functionality.
I have not looked at the code in detail but a couple of questions related to the implementation come to mind: (1) Why not use a single compressed event type and encapsulate the whole original event inside ? Is it not possible to have a "generic compressed event”? Mark mentions allowing selection of the compression type and that seems useful and I would expect the the compressed event to have this information and the compressed content. (2) Senders would try to compress the event as requested. If the compressed event is not any smaller then do not bother compressing it, just send the original event. (3) Receivers on receiving a compressed event would decompress it and then process the extracted event in the same way it’s processed now. Most of the code should haven no idea the event had been compressed. (4) This logic would only require a single new event type and also allow all types of events (including any future ones) to be compressed without requiring extra logic Perhaps I am missing something but the need to compress events individually probably requires quite a bit more logic and will not be as extensible. Thanks for sharing any thoughts on this. Regards, Simon [1] See: https://bugs.mysql.com/bug.php?id=71696 and various other FRs related to this topic. _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
