blob: 4588aaeebc48e53fad1a4830c4b4a74d5b00bc5c [file] [log] [blame]
drh4fb48e42016-03-01 22:41:27 +00001# 2014-10-04
dan4ee3eb02014-10-04 10:22:01 +00002#
3# The author disclaims copyright to this source code. In place of
4# a legal notice, here is a blessing:
5#
6# May you do good and not evil.
7# May you find forgiveness for yourself and forgive others.
8# May you share freely, never taking more than you give.
9#
10#***********************************************************************
11# This file implements regression tests for SQLite library.
12# This file implements tests for the ANALYZE command.
13#
dan4ee3eb02014-10-04 10:22:01 +000014
15set testdir [file dirname $argv0]
16source $testdir/tester.tcl
17set ::testprefix analyzeD
18
19ifcapable {!stat4} {
20 finish_test
21 return
22}
23
24
25# Set up a table with the following properties:
26#
27# * Contains 1000 rows.
28# * Column a contains even integers between 0 and 18, inclusive (so that
29# a=? for any such integer matches 100 rows).
30# * Column b contains integers between 0 and 9, inclusive.
31# * Column c contains integers between 0 and 199, inclusive (so that
32# for any such integer, c=? matches 5 rows).
33# * Then add 7 rows with a new value for "a" - 3001. The stat4 table will
34# not contain any samples with a=3001.
35#
36do_execsql_test 1.0 {
37 CREATE TABLE t1(a, b, c);
38}
39do_test 1.1 {
40 for {set i 1} {$i < 1000} {incr i} {
41 set c [expr $i % 200]
42 execsql { INSERT INTO t1(a, b, c) VALUES( 2*($i/100), $i%10, $c ) }
43 }
44
45 execsql {
46 INSERT INTO t1 VALUES(3001, 3001, 3001);
47 INSERT INTO t1 VALUES(3001, 3001, 3002);
48 INSERT INTO t1 VALUES(3001, 3001, 3003);
49 INSERT INTO t1 VALUES(3001, 3001, 3004);
50 INSERT INTO t1 VALUES(3001, 3001, 3005);
51 INSERT INTO t1 VALUES(3001, 3001, 3006);
52 INSERT INTO t1 VALUES(3001, 3001, 3007);
53
54 CREATE INDEX t1_ab ON t1(a, b);
55 CREATE INDEX t1_c ON t1(c);
56
57 ANALYZE;
58 }
59} {}
60
61# With full ANALYZE data, SQLite sees that c=150 (5 rows) is better than
62# a=3001 (7 rows).
63#
64do_eqp_test 1.2 {
65 SELECT * FROM t1 WHERE a=3001 AND c=150;
66} {
67 0 0 0 {SEARCH TABLE t1 USING INDEX t1_c (c=?)}
68}
69
70do_test 1.3 {
71 execsql { DELETE FROM sqlite_stat1 }
72 db close
73 sqlite3 db test.db
74} {}
75
76# Without stat1, because 3001 is larger than all samples in the stat4
drh4fb48e42016-03-01 22:41:27 +000077# table, SQLite thinks that a=3001 matches just 1 row. So it (incorrectly)
dan4ee3eb02014-10-04 10:22:01 +000078# chooses it over the c=150 index (5 rows). Even with stat1 data, things
79# worked this way before commit [e6f7f97dbc].
80#
81do_eqp_test 1.4 {
82 SELECT * FROM t1 WHERE a=3001 AND c=150;
83} {
84 0 0 0 {SEARCH TABLE t1 USING INDEX t1_ab (a=?)}
85}
86
87do_test 1.5 {
88 execsql {
89 UPDATE t1 SET a=13 WHERE a = 3001;
90 ANALYZE;
91 }
92} {}
93
94do_eqp_test 1.6 {
95 SELECT * FROM t1 WHERE a=13 AND c=150;
96} {
97 0 0 0 {SEARCH TABLE t1 USING INDEX t1_c (c=?)}
98}
99
100do_test 1.7 {
101 execsql { DELETE FROM sqlite_stat1 }
102 db close
103 sqlite3 db test.db
104} {}
105
106# Same test as 1.4, except this time the 7 rows that match the a=? condition
107# do not feature larger values than all rows in the stat4 table. So SQLite
108# gets this right, even without stat1 data.
109do_eqp_test 1.8 {
110 SELECT * FROM t1 WHERE a=13 AND c=150;
111} {
112 0 0 0 {SEARCH TABLE t1 USING INDEX t1_c (c=?)}
113}
114
115finish_test