DB-803 fix the 5733 test to be more tolerant of join type

mysql-test/suite/tokudb.bugs/r/5733_tokudb.result

@@ -10003,7 +10003,7 @@ insert into t values (9998,0);
 insert into t values (9999,0);
 explain select id from t where id>0 limit 10;
 id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
-1	SIMPLE	t	range	PRIMARY	PRIMARY	8	NULL	#	Using where; Using index
+1	SIMPLE	t	range_or_index	PRIMARY	PRIMARY	8	NULL	#	Using where; Using index
 explain select * from t where id>0 limit 10;
 id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
 1	SIMPLE	t	range	PRIMARY	PRIMARY	8	NULL	#	Using where

mysql-test/suite/tokudb.bugs/t/5733_tokudb.test

@@ -18,7 +18,18 @@ while ($i < $n) {
       inc $i;
 }
 
-replace_column 9 #;
+# the plan for the following query should be a range scan.  about 1 of 10 times,
+# the plan is an index scan.  the different scan type occurs because the query optimizer
+# is handed different row counts by tokudb::records_in_range.  the cost estimates made
+# by the query optimizer are very close to begin with.  sometimes, the cost of an index
+# scan is less than the cost of a range scan.
+#
+# if a tokudb checkpoint occurs before this query is run, then the records_in_range
+# function returns a larger than expected row estimate.
+#
+# column 4 is the join type (should be range or index)
+# column 9 is the estimated key count
+replace_column 4 range_or_index 9 #;
 explain select id from t where id>0 limit 10;
 
 replace_column 9 #;