Make MyRocks range scan cost calculation more accurate (percona#212)

Summary:
MyRocks had two bugs when calculating index scan cost.
1. block_size was not considered. This made covering index scan cost
(both full index scan and range scan) much higher
2. ha_rocksdb::records_in_range() may have estimated more rows
than the estimated number of rows in the table. This was wrong,
and MySQL optimizer decided to use full index scan even though
range scan was more efficient.

This diff fixes #1 by setting stats.block_size at ha_rocksdb::open(),
and fixes #2 by reducing the number of estimated rows if it was
larger than stats.records.

Test Plan:
mtr, updating some affected test cases, and new test case
rocksdb_range2

Reviewers: hermanlee4, jkedgar, spetrunia

Reviewed By: spetrunia

Subscribers: MarkCallaghan, webscalesql-eng

Differential Revision: https://reviews.facebook.net/D55869

storage/rocksdb/ha_rocksdb.cc

@@ -3788,6 +3788,9 @@ int ha_rocksdb::open(const char *name, int mode, uint test_if_locked)
   if (has_hidden_pk(table) && load_hidden_pk_value())
     DBUG_RETURN(HA_ERR_INTERNAL_ERROR);
 
+  /* Index block size in MyRocks: used by MySQL in query optimization */
+  stats.block_size = table_options.block_size;
+
   DBUG_RETURN(0);
 }
 
@@ -7484,6 +7487,19 @@ ha_rows ha_rocksdb::records_in_range(uint inx, key_range *min_key,
   }
 
   ret = rows*sz/disk_size;
+
+  /*
+    GetApproximateSizes() gives estimates so ret might exceed stats.records.
+    MySQL then decides to use full index scan rather than range scan, which
+    is not efficient for most cases.
+    To prevent this, changing estimated records slightly smaller than
+    stats.records.
+  */
+  if (ret >= stats.records)
+  {
+    ret = stats.records * 0.99;
+  }
+
   if (rocksdb_debug_optimizer_n_rows > 0)
   {
     ret= rocksdb_debug_optimizer_n_rows;