mirror of
https://github.com/sqlite/sqlite.git
synced 2024-11-25 08:59:33 +01:00
116 lines
3.5 KiB
Plaintext
116 lines
3.5 KiB
Plaintext
# 2011 August 13
|
|
#
|
|
# The author disclaims copyright to this source code. In place of
|
|
# a legal notice, here is a blessing:
|
|
#
|
|
# May you do good and not evil.
|
|
# May you find forgiveness for yourself and forgive others.
|
|
# May you share freely, never taking more than you give.
|
|
#
|
|
#***********************************************************************
|
|
#
|
|
# This file implements tests for SQLite library. The focus of the tests
|
|
# in this file is testing the capabilities of sqlite_stat4.
|
|
#
|
|
|
|
set testdir [file dirname $argv0]
|
|
source $testdir/tester.tcl
|
|
|
|
ifcapable !stat4 {
|
|
finish_test
|
|
return
|
|
}
|
|
|
|
set testprefix analyze8
|
|
|
|
proc eqp {sql {db db}} {
|
|
uplevel execsql [list "EXPLAIN QUERY PLAN $sql"] $db
|
|
}
|
|
|
|
# Scenario:
|
|
#
|
|
# Two indices. One has mostly singleton entries, but for a few
|
|
# values there are hundreds of entries. The other has 10-20
|
|
# entries per value.
|
|
#
|
|
# Verify that the query planner chooses the first index for the singleton
|
|
# entries and the second index for the others.
|
|
#
|
|
do_test 1.0 {
|
|
db eval {
|
|
CREATE TABLE t1(a,b,c,d);
|
|
CREATE INDEX t1a ON t1(a);
|
|
CREATE INDEX t1b ON t1(b);
|
|
CREATE INDEX t1c ON t1(c);
|
|
}
|
|
for {set i 0} {$i<1000} {incr i} {
|
|
if {$i%2==0} {set a $i} {set a [expr {($i%8)*100}]}
|
|
set b [expr {$i/10}]
|
|
set c [expr {$i/8}]
|
|
set c [expr {$c*$c*$c}]
|
|
db eval {INSERT INTO t1 VALUES($a,$b,$c,$i)}
|
|
}
|
|
db eval {ANALYZE}
|
|
} {}
|
|
|
|
# The a==100 comparison is expensive because there are many rows
|
|
# with a==100. And so for those cases, choose the t1b index.
|
|
#
|
|
# Buf ro a==99 and a==101, there are far fewer rows so choose
|
|
# the t1a index.
|
|
#
|
|
do_test 1.1 {
|
|
eqp {SELECT * FROM t1 WHERE a=100 AND b=55}
|
|
} {/*SEARCH t1 USING INDEX t1b (b=?)*/}
|
|
do_test 1.2 {
|
|
eqp {SELECT * FROM t1 WHERE a=99 AND b=55}
|
|
} {/*SEARCH t1 USING INDEX t1a (a=?)*/}
|
|
do_test 1.3 {
|
|
eqp {SELECT * FROM t1 WHERE a=101 AND b=55}
|
|
} {/*SEARCH t1 USING INDEX t1a (a=?)*/}
|
|
do_test 1.4 {
|
|
eqp {SELECT * FROM t1 WHERE a=100 AND b=56}
|
|
} {/*SEARCH t1 USING INDEX t1b (b=?)*/}
|
|
do_test 1.5 {
|
|
eqp {SELECT * FROM t1 WHERE a=99 AND b=56}
|
|
} {/*SEARCH t1 USING INDEX t1a (a=?)*/}
|
|
do_test 1.6 {
|
|
eqp {SELECT * FROM t1 WHERE a=101 AND b=56}
|
|
} {/*SEARCH t1 USING INDEX t1a (a=?)*/}
|
|
do_test 2.1 {
|
|
eqp {SELECT * FROM t1 WHERE a=100 AND b BETWEEN 50 AND 54}
|
|
} {/*SEARCH t1 USING INDEX t1b (b>? AND b<?)*/}
|
|
|
|
# There are many more values of c between 0 and 100000 than there are
|
|
# between 800000 and 900000. So t1c is more selective for the latter
|
|
# range.
|
|
#
|
|
# Test 3.2 is a little unstable. It depends on the planner estimating
|
|
# that (b BETWEEN 30 AND 34) will match more rows than (c BETWEEN
|
|
# 800000 AND 900000). Which is a pretty close call (50 vs. 32), so
|
|
# the planner could get it wrong with an unlucky set of samples. This
|
|
# case happens to work, but others ("b BETWEEN 40 AND 44" for example)
|
|
# will fail.
|
|
#
|
|
do_execsql_test 3.0 {
|
|
SELECT count(*) FROM t1 WHERE b BETWEEN 30 AND 34;
|
|
SELECT count(*) FROM t1 WHERE c BETWEEN 0 AND 100000;
|
|
SELECT count(*) FROM t1 WHERE c BETWEEN 800000 AND 900000;
|
|
} {50 376 32}
|
|
do_test 3.1 {
|
|
eqp {SELECT * FROM t1 WHERE b BETWEEN 30 AND 34 AND c BETWEEN 0 AND 100000}
|
|
} {/*SEARCH t1 USING INDEX t1b (b>? AND b<?)*/}
|
|
do_test 3.2 {
|
|
eqp {SELECT * FROM t1
|
|
WHERE b BETWEEN 30 AND 34 AND c BETWEEN 800000 AND 900000}
|
|
} {/*SEARCH t1 USING INDEX t1c (c>? AND c<?)*/}
|
|
do_test 3.3 {
|
|
eqp {SELECT * FROM t1 WHERE a=100 AND c BETWEEN 0 AND 100000}
|
|
} {/*SEARCH t1 USING INDEX t1a (a=?)*/}
|
|
do_test 3.4 {
|
|
eqp {SELECT * FROM t1
|
|
WHERE a=100 AND c BETWEEN 800000 AND 900000}
|
|
} {/*SEARCH t1 USING INDEX t1c (c>? AND c<?)*/}
|
|
|
|
finish_test
|