olafbuitelaar, thank you for your feedback. ALTER TABLE should only read the clustered index, not secondary indexes. In fact, rebuilding a table would fix corrupted secondary indexes (I hope that MDEV-22373 is fixed now, but it is too early to tell).

I hope that page_compressed together with compressed columns (MDEV-11371) would make an acceptable replacement of ROW_FORMAT=COMPRESSED. One piece that is missing is something that allows us to avoid the problematic use of sparse files in page_compressed. I think that we must provide an option to write page_compressed tables as normal non-sparse files and let the a smart SSD compress away the sequences of zero bytes, as explained in https://mariadb.org/fest2020/ssd/.

Are there any creditable benchmarks on the CPU, I/O, and disk space for ROW_FORMAT=COMPRESSED? I have long been skeptical about the feature. I will continue to steer people away from using that setting.

Based on https://github.com/nextcloud/server/issues/25436 NextCloud appears to be using ROW_FORMAT=COMPRESSED for InnoDB tables.

rjasdfiii, I remember that back in 2006 or 2007, when I had completed the implementation of ROW_FORMAT=COMPRESSED for the InnoDB Plugin for MySQL 5.0 based on some rough ideas of Heikki Tuuri, some performance tests were run, and the results were not great. I think that we really have to compare all performance aspects to page_compressed, as suggested in MDEV-22839.

MDEV-27736 in MariaDB Server 10.6.6 essentially reverted this change, by changing the default value of innodb_read_only_compressed to OFF. The plan to remove support for InnoDB ROW_FORMAT=COMPRESSED tables (MDEV-22367) has been cancelled.