Simon Mudd <[email protected]> writes: >> This would result in higher overhead on each event. There is a fixed header
> Ok. I’ve been assuming the headers were small (from some casual browsing of > things > related to the binlog router some time ago), but that may be wrong. Yes, they are quite small, 10-20 bytes per event or something like that. > Indeed, one of the things about the current binlog format is that there’s > little > complete documentation outside of the code. Code changes and there’s no > clear specification. It makes things much better if what’s currently implicit > is > explicit and also if the specs are outside of the code. That’s something I Tell me about it ... it is _very_ hard to change most anything in replication without breaking some odd corner somewhere. > Fixing the case for RBR is good but I feel the focus may be too narrow, > especially if the approach can be used more generically. > > I certainly have some SBR machines which generate large volumes of bin logs > and to be able to compress the events they generate on disk would be most > helpful. Right. This patch compresses query events (ie. statement-based updates) and row-events, so both of these are covered. LOAD DATA INFILE in statement mode is not (but in row-based mode it should be, I think). - Kristian. _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
