mirror of
https://github.com/MariaDB/server.git
synced 2025-09-02 09:41:40 +03:00
59 lines
1.6 KiB
Plaintext
59 lines
1.6 KiB
Plaintext
# 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;
|