Kristian,

thank you for the observation. I would be careful with this. The code assumes that compressBound() be an accurate upper bound. If it is too low, modifications may occasionally fail.

It is not a good idea to make KEY_BLOCK_SIZE too low anyway. If the table is read-only, you are probably better off with compressed MyISAM tables. If the table is updated, a "too large" compressed page size will make InnoDB run faster, because the page doesn't have to be recompressed after every operation.

Your observation reminds me of a design decision that I made regarding redo logging: Whenever a page is recompressed, we write all the compressed data to the InnoDB redo log. This will cause more redo log I/O, but it will also be compatible with different zlib versions that might compress differently. We could reduce the redo log I/O by writing a logical log entry "compress this page" instead of the current physical log entry "compressed the page to these bytes", but then the crash recovery should use the exactly same version of zlib, so that the compressed payload size will not change.

Best regards,

Marko Mäkelä
Innobase Oy/Oracle Corp.