buf_pool.unzip_LRU wastes memory and CPU

One of the original design goals of InnoDB ROW_FORMAT=COMPRESSED was to improve performance in the case that the working set does not fully fit in the buffer pool, but it does when the data is compressed.

I validated this design goal by using a Sysbench oltp_read_write workload with 16 tables of 10,000 rows each, running 96 concurrent connections for 120 seconds. The total size of the .ibd files at the end of this test would be about 230MiB uncompressed, and 129MiB when using ROW_FORMAT=COMPRESSED and the default innodb_page_size=16k.

When I use innodb_buffer_pool_size=64m and normal uncompressed tables, I start to see a small decline in the average throughput: about 251,501 queries per second instead of 271,299 at innodb_buffer_pool_size=128m. With ROW_FORMAT=COMPRESSED the decline is much more severe, dropping from 148,000 qps to 74,000 qps. If I remove buf_pool.unzip_LRU, then the decline will be even more, to about 64,000 qps. At innodb_buffer_pool_size=32m the throughput drops to 56,537 or 43,703 queries per second. The penalty of removing unzip_LRU would be 22.7% for this low-buffer-pool situation.

However, if we use innodb_buffer_pool_size=128m, the throughput of the ROW_FORMAT=COMPRESSED workload will increase from some 148,000 qps to 163,214 qps (an improvement of 10%). Note: when using normal uncompressed tables at the same buffer pool size, I get 271,299 qps. All these figures were produced on RAM disk (Linux /dev/shm).

The utility of buf_pool.unzip_LRU seems to be rather limited even in those cases that it was designed for: where the working set is much larger than the buffer pool. It would seem to make sense to remove it. This would shrink sizeof(buf_block_t) by 2 pointers, or 16 bytes (10%) on a 64-bit system, and it would seem to improve performance for workloads that do not involve heavy thrashing.