Fix a problem in where.c with using the stat4 sample data of an index on a WITHOUT ROWID table.

FossilOrigin-Name: 053a210e3169732c58f84cb54c9b6f6df3a8f4ea

manifest

@@ -1,5 +1,5 @@
-C Fix\sthe\sSTAT4\sinformation\sfor\sWITHOUT\sROWID\stables.
-D 2014-06-30T17:07:39.466
+C Fix\sa\sproblem\sin\swhere.c\swith\susing\sthe\sstat4\ssample\sdata\sof\san\sindex\son\sa\sWITHOUT\sROWID\stable.
+D 2014-06-30T18:02:20.849
 F Makefile.arm-wince-mingw32ce-gcc d6df77f1f48d690bd73162294bbba7f59507c72f
 F Makefile.in 1732320ecac3fee229d560d7ef2afa34681d1815
 F Makefile.linux-gcc 91d710bdc4998cb015f39edf3cb314ec4f4d7e23
@@ -296,7 +296,7 @@ F src/vtab.c 21b932841e51ebd7d075e2d0ad1415dce8d2d5fd
 F src/wal.c 264df50a1b33124130b23180ded2e2c5663c652a
 F src/wal.h df01efe09c5cb8c8e391ff1715cca294f89668a4
 F src/walker.c 11edb74d587bc87b33ca96a5173e3ec1b8389e45
-F src/where.c da15506cd52de8717836921da8ebd9109228f94e
+F src/where.c 2bc0226fced128686c432748324351beb127829b
 F src/whereInt.h 929c1349b5355fd44f22cee5c14d72b3329c58a6
 F test/8_3_names.test ebbb5cd36741350040fd28b432ceadf495be25b2
 F test/aggerror.test a867e273ef9e3d7919f03ef4f0e8c0d2767944f2
@@ -316,7 +316,7 @@ F test/analyze5.test 765c4e284aa69ca172772aa940946f55629bc8c4
 F test/analyze6.test d31defa011a561b938b4608d3538c1b4e0b5e92c
 F test/analyze7.test bb1409afc9e8629e414387ef048b8e0e3e0bdc4f
 F test/analyze8.test 093d15c1c888eed5034304a98c992f7360130b88
-F test/analyze9.test 623e02a99a78fa12fe5def2fd559032d5d887e0f
+F test/analyze9.test 93619368fff2db833747a6dfa9b1146a82e5d4d2
 F test/analyzeA.test 1a5c40079894847976d983ca39c707aaa44b6944
 F test/analyzeB.test 8bf35ee0a548aea831bf56762cb8e7fdb1db083d
 F test/async.test 1d0e056ba1bb9729283a0f22718d3a25e82c277b
@@ -1181,7 +1181,7 @@ F tool/vdbe_profile.tcl 67746953071a9f8f2f668b73fe899074e2c6d8c1
 F tool/warnings-clang.sh f6aa929dc20ef1f856af04a730772f59283631d4
 F tool/warnings.sh 0abfd78ceb09b7f7c27c688c8e3fe93268a13b32
 F tool/win/sqlite.vsix deb315d026cc8400325c5863eef847784a219a2f
-P 6624a61d16e47ad691c4195ca8a1d68b7348118d
-R 54d510c828cc71c8f4dcbc102dfc2a66
-U drh
-Z 6aa7249d11aa6d73980f37e6212dc38c
+P 5d8628fdffbcf837313958f0ee1ed8a2043d384e
+R 48fee5f306f007e5e5bc0779449b568d
+U dan
+Z 6e1427ceae354dbee93842f8dd267647

manifest.uuid

@@ -1 +1 @@
-5d8628fdffbcf837313958f0ee1ed8a2043d384e
+053a210e3169732c58f84cb54c9b6f6df3a8f4ea

src/where.c

@@ -2201,7 +2201,7 @@ static int whereEqualScanEst(
   int bOk;
 
   assert( nEq>=1 );
-  assert( nEq<=(p->nKeyCol+1) );
+  assert( nEq<=p->nColumn );
   assert( p->aSample!=0 );
   assert( p->nSample>0 );
   assert( pBuilder->nRecValid<nEq );
@@ -2214,7 +2214,7 @@ static int whereEqualScanEst(
 
   /* This is an optimization only. The call to sqlite3Stat4ProbeSetValue()
   ** below would return the same value.  */
-  if( nEq>p->nKeyCol ){
+  if( nEq>=p->nColumn ){
     *pnRow = 1;
     return SQLITE_OK;
   }

test/analyze9.test

@@ -953,4 +953,72 @@ for {set i 0} {$i<16} {incr i} {
     } {1}
 }
 
+#-------------------------------------------------------------------------
+#
+reset_db
+
+do_execsql_test 21.0 {
+  CREATE TABLE t2(a, b);
+  CREATE INDEX i2 ON t2(a);
+}
+
+do_test 21.1 {
+  for {set i 1} {$i < 100} {incr i} {
+    execsql { 
+      INSERT INTO t2 VALUES(CASE WHEN $i < 80 THEN 'one' ELSE 'two' END, $i) 
+    }
+  }
+  execsql ANALYZE
+} {}
+
+# Condition (a='one') matches 80% of the table. (rowid<10) reduces this to
+# 10%, but (rowid<50) only reduces it to 50%. So in the first case below
+# the index is used. In the second, it is not. 
+#
+do_eqp_test 21.2 {
+  SELECT * FROM t2 WHERE a='one' AND rowid < 10
+} {/*USING INDEX i2 (a=? AND rowid<?)*/}
+do_eqp_test 21.3 {
+  SELECT * FROM t2 WHERE a='one' AND rowid < 50
+} {/*USING INTEGER PRIMARY KEY*/}
+
+#-------------------------------------------------------------------------
+#
+reset_db
+do_execsql_test 22.0 {
+  CREATE TABLE t3(a, b, c, d, PRIMARY KEY(a, b)) WITHOUT ROWID;
+}
+do_execsql_test 22.1 {
+  WITH r(x) AS (
+    SELECT 1
+    UNION ALL
+    SELECT x+1 FROM r WHERE x<=100
+  )
+
+  INSERT INTO t3 SELECT
+    CASE WHEN (x>45 AND x<96) THEN 'B' ELSE 'A' END,  /* Column "a" */
+    x,                                                /* Column "b" */
+    CASE WHEN (x<51) THEN 'one' ELSE 'two' END,       /* Column "c" */
+    x                                                 /* Column "d" */
+  FROM r;
+
+  CREATE INDEX i3 ON t3(c);
+  CREATE INDEX i4 ON t3(d);
+  ANALYZE;
+}
+
+# Expression (c='one' AND a='B') matches 5 table rows. But (c='one' AND a=A')
+# matches 45. Expression (d<?) matches 20. Neither index is a covering index.
+#
+# Therefore, with stat4 data, SQLite prefers (c='one' AND a='B') over (d<20),
+# and (d<20) over (c='one' AND a='A').
+foreach {tn where res} {
+  1 "c='one' AND a='B' AND d < 20"   {/*INDEX i3 (c=? AND a=?)*/}
+  2 "c='one' AND a='A' AND d < 20"   {/*INDEX i4 (d<?)*/}
+} {
+  do_eqp_test 22.2.$tn "SELECT * FROM t3 WHERE $where" $res
+}
+
 finish_test
+
+