blob: 192004cb11326c6ff002c5f3e14e94a99f55814e (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
|
# test that query planner selects range scan rather than full scan of the primary key
# see ticket #5733
source include/have_tokudb.inc;
disable_warnings;
drop table if exists t;
enable_warnings;
set default_storage_engine='tokudb';
create table t (id bigint primary key, x bigint not null);
begin;
let $i=0;
let $n=10000;
while ($i < $n) {
eval insert into t values ($i,0);
inc $i;
}
commit;
# 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 #;
explain select * from t where id>0 limit 10;
replace_column 9 #;
explain select id from t where id>1000 limit 10;
replace_column 9 #;
explain select * from t where id>1000 limit 10;
replace_column 9 #;
explain select id from t where id>5000 limit 10;
replace_column 9 #;
explain select * from t where id>5000 limit 10;
replace_column 9 #;
explain select id from t where id>6000 limit 10;
replace_column 9 #;
explain select * from t where id>6000 limit 10;
drop table t;
|
