Add the analyze8.test test module for sqlite_stat3.

FossilOrigin-Name: 2c83ac89dc5a6017587defb541c9f3731b98892a

diff --git a/manifest b/manifest
index 6e35346e9a58a914de7f837d506a35905c64ead0..dfb25817e07a44a39193c23a93e51fca128ee1ee 100644 (file)
--- a/manifest
+++ b/manifest
@@ -1,5 +1,5 @@
-C Update\ssome\stest\scases\sto\swork\swith\ssqlite_stat3\sinstead\sof\ssqlite_stat2.
-D 2011-08-15T12:58:23.538
+C Add\sthe\sanalyze8.test\stest\smodule\sfor\ssqlite_stat3.
+D 2011-08-16T01:15:12.193
 F Makefile.arm-wince-mingw32ce-gcc d6df77f1f48d690bd73162294bbba7f59507c72f
 F Makefile.in 1e6988b3c11dee9bd5edc0c804bd4468d74a9cdc
 F Makefile.linux-gcc 91d710bdc4998cb015f39edf3cb314ec4f4d7e23
@@ -267,6 +267,7 @@ F test/analyze4.test 757b37875cf9bb528d46f74497bc789c88365045
 F test/analyze5.test 713354664c5ff1853ab2cbcb740f0cf5cb7c802e
 F test/analyze6.test bd3625806a5ee6f7bef72d06295bd319f0290af2
 F test/analyze7.test d3587aa5af75c9048d031b94fceca2534fa75d1d
+F test/analyze8.test 4ca170de2ba30ccb1af2c0406803db72262f9691
 F test/async.test 1d0e056ba1bb9729283a0f22718d3a25e82c277b
 F test/async2.test c0a9bd20816d7d6a2ceca7b8c03d3d69c28ffb8b
 F test/async3.test d73a062002376d7edc1fe3edff493edbec1fc2f7
@@ -958,7 +959,7 @@ F tool/symbols.sh caaf6ccc7300fd43353318b44524853e222557d5
 F tool/tostr.awk 11760e1b94a5d3dcd42378f3cc18544c06cfa576
 F tool/vdbe-compress.tcl d70ea6d8a19e3571d7ab8c9b75cba86d1173ff0f
 F tool/warnings.sh 2ebae31e1eb352696f3c2f7706a34c084b28c262
-P ae31dc67aa0637150f964de31a6da6f5797b462a
-R db03066face0c75eaaff8230204f24b2
+P 2504bcfb0cf14b5ce51db0af1269ac28384714e0
+R 5a73b64fef41c0e56d473c9564281bab
 U drh
-Z 4658be3708d6f87baa530d35bdb7827f
+Z db81907234b1038bee781d0d0d68d5d7

diff --git a/manifest.uuid b/manifest.uuid
index fd01eb5171ba45fd63303d9636c6e7364f8bad68..64e6a035d28255fd22ea6d6370378e826cb97ad9 100644 (file)
--- a/manifest.uuid
+++ b/manifest.uuid
@@ -1 +1 @@
-2504bcfb0cf14b5ce51db0af1269ac28384714e0
\ No newline at end of file
+2c83ac89dc5a6017587defb541c9f3731b98892a
\ No newline at end of file

diff --git a/test/analyze8.test b/test/analyze8.test
new file mode 100644 (file)
index 0000000..f3e2710
--- /dev/null
+++ b/test/analyze8.test
@@ -0,0 +1,103 @@
+# 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_stat3.
+#
+
+set testdir [file dirname $argv0]
+source $testdir/tester.tcl
+
+ifcapable !stat3 {
+  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}
+} {0 0 0 {SEARCH TABLE t1 USING INDEX t1b (b=?) (~2 rows)}}
+do_test 1.2 {
+  eqp {SELECT * FROM t1 WHERE a=99 AND b=55}
+} {0 0 0 {SEARCH TABLE t1 USING INDEX t1a (a=?) (~1 rows)}}
+do_test 1.3 {
+  eqp {SELECT * FROM t1 WHERE a=101 AND b=55}
+} {0 0 0 {SEARCH TABLE t1 USING INDEX t1a (a=?) (~1 rows)}}
+do_test 1.4 {
+  eqp {SELECT * FROM t1 WHERE a=100 AND b=56}
+} {0 0 0 {SEARCH TABLE t1 USING INDEX t1b (b=?) (~2 rows)}}
+do_test 1.5 {
+  eqp {SELECT * FROM t1 WHERE a=99 AND b=56}
+} {0 0 0 {SEARCH TABLE t1 USING INDEX t1a (a=?) (~1 rows)}}
+do_test 1.6 {
+  eqp {SELECT * FROM t1 WHERE a=101 AND b=56}
+} {0 0 0 {SEARCH TABLE t1 USING INDEX t1a (a=?) (~1 rows)}}
+do_test 2.1 {
+  eqp {SELECT * FROM t1 WHERE a=100 AND b BETWEEN 50 AND 54}
+} {0 0 0 {SEARCH TABLE t1 USING INDEX t1b (b>? AND b<?) (~2 rows)}}
+
+# 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.
+#
+do_test 3.1 {
+  eqp {SELECT * FROM t1 WHERE b BETWEEN 50 AND 54 AND c BETWEEN 0 AND 100000}
+} {0 0 0 {SEARCH TABLE t1 USING INDEX t1b (b>? AND b<?) (~6 rows)}}
+do_test 3.2 {
+  eqp {SELECT * FROM t1
+       WHERE b BETWEEN 50 AND 54 AND c BETWEEN 800000 AND 900000}
+} {0 0 0 {SEARCH TABLE t1 USING INDEX t1c (c>? AND c<?) (~4 rows)}}
+do_test 3.3 {
+  eqp {SELECT * FROM t1 WHERE a=100 AND c BETWEEN 0 AND 100000}
+} {0 0 0 {SEARCH TABLE t1 USING INDEX t1a (a=?) (~63 rows)}}
+do_test 3.4 {
+  eqp {SELECT * FROM t1
+       WHERE a=100 AND c BETWEEN 800000 AND 900000}
+} {0 0 0 {SEARCH TABLE t1 USING INDEX t1c (c>? AND c<?) (~2 rows)}}
+
+finish_test