Investigate this patch and see if it is worth eventually taking it. MRR seems pretty invasive in the optimizer and kid of automatically makes me scream no. I am unsure of the overall performance implication of it though, it could be significant for certain use cases.
Investigate this patch and see if it is worth eventually taking it. MRR seems pretty invasive in the optimizer and kid of automatically makes me scream no. I am unsure of the overall performance implication of it though, it could be significant for certain use cases.
See fb-mysql-5.6.35 work :
https://github.com/facebook/mysql-5.6/commit/45110dcda26 [Issue790: MultiGet-MRR implementation]
https://github.com/facebook/mysql-5.6/commit/be12c8cfb44 [Stabilize rocksdb.rocksdb_mrr]
https://github.com/facebook/mysql-5.6/commit/d0c98c1e6a5 [Fix rocksdb.rocksdb_mrr]
https://github.com/facebook/mysql-5.6/commit/e99310c1197 [MRR should honor buffer size limit specify by read_rnd_buffer_size]
https://github.com/facebook/mysql-5.6/commit/888d47893f1 [Add rocksdb_mrr_batch_size_basic testcase]
https://github.com/facebook/mysql-5.6/commit/40d6766e57b [initialize mrr_iter for RANGE_SEQ_IF::skip_record scenario]
See fb-mysql-8.0.17 work :
https://github.com/facebook/mysql-5.6/commit/48dfd8c710b [MultiGet-MRR implementation]
https://github.com/facebook/mysql-5.6/commit/4b3095a64ca [Fix MRR to not double count ranges]
https://github.com/facebook/mysql-5.6/commit/a31862b9b90 [Add sorted MRR support for secondary key ref plans]