Remove the MySQL upsert syntax. As an optional alias to the insert table
[sqlite.git] / test / analyzeD.test
blob4588aaeebc48e53fad1a4830c4b4a74d5b00bc5c
1 # 2014-10-04
3 # The author disclaims copyright to this source code.  In place of
4 # a legal notice, here is a blessing:
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.
10 #***********************************************************************
11 # This file implements regression tests for SQLite library.
12 # This file implements tests for the ANALYZE command.
15 set testdir [file dirname $argv0]
16 source $testdir/tester.tcl
17 set ::testprefix analyzeD
19 ifcapable {!stat4} {
20   finish_test
21   return
25 # Set up a table with the following properties:
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.
36 do_execsql_test 1.0 {
37   CREATE TABLE t1(a, b, c);
39 do_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   }
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);
54     CREATE INDEX t1_ab ON t1(a, b);
55     CREATE INDEX t1_c ON t1(c);
57     ANALYZE;
58   }
59 } {}
61 # With full ANALYZE data, SQLite sees that c=150 (5 rows) is better than
62 # a=3001 (7 rows).
64 do_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=?)}
70 do_test 1.3 {
71   execsql { DELETE FROM sqlite_stat1 }
72   db close
73   sqlite3 db test.db
74 } {}
76 # Without stat1, because 3001 is larger than all samples in the stat4
77 # table, SQLite thinks that a=3001 matches just 1 row. So it (incorrectly)
78 # chooses it over the c=150 index (5 rows). Even with stat1 data, things
79 # worked this way before commit [e6f7f97dbc].
81 do_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=?)}
87 do_test 1.5 {
88   execsql { 
89     UPDATE t1 SET a=13 WHERE a = 3001;
90     ANALYZE;
91   }
92 } {}
94 do_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=?)}
100 do_test 1.7 {
101   execsql { DELETE FROM sqlite_stat1 }
102   db close
103   sqlite3 db test.db
104 } {}
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.
109 do_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=?)}
115 finish_test