From: dan Date: Wed, 30 Apr 2014 18:11:55 +0000 (+0000) Subject: Fix a problem in calculating the costs of "OR" scans. X-Git-Tag: version-3.8.5~64 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=5da73e1a09b89f3605af1e438ac5e269969015f5;p=thirdparty%2Fsqlite.git Fix a problem in calculating the costs of "OR" scans. FossilOrigin-Name: 9bbca48b42e4fe16f2188e18dc736da30a96435c --- diff --git a/manifest b/manifest index c2ff19fbfe..88f6a39dac 100644 --- a/manifest +++ b/manifest @@ -1,5 +1,5 @@ -C Modify\sthe\sway\sthe\scosts\sof\svarious\squery\splans\sare\sestimated.\sIf\sthe\suser\ssupplies\sa\slikelihood()\svalue\s(or\sequivalent)\son\san\sindexed\sWHERE\sconstraint,\suse\sit\sto\sestimate\sthe\snumber\sof\sindex\srows\svisited. -D 2014-04-30T15:22:25.359 +C Fix\sa\sproblem\sin\scalculating\sthe\scosts\sof\s"OR"\sscans. +D 2014-04-30T18:11:55.566 F Makefile.arm-wince-mingw32ce-gcc d6df77f1f48d690bd73162294bbba7f59507c72f F Makefile.in 2ef13430cd359f7b361bb863504e227b25cc7f81 F Makefile.linux-gcc 91d710bdc4998cb015f39edf3cb314ec4f4d7e23 @@ -292,7 +292,7 @@ F src/vtab.c 21b932841e51ebd7d075e2d0ad1415dce8d2d5fd F src/wal.c 76e7fc6de229bea8b30bb2539110f03a494dc3a8 F src/wal.h df01efe09c5cb8c8e391ff1715cca294f89668a4 F src/walker.c 11edb74d587bc87b33ca96a5173e3ec1b8389e45 -F src/where.c 4aeb1caa0a16c76e0c0566af4c64ba003836a0aa +F src/where.c 3eaf3d241d86452c0f21aa3fe2b5df25d8c99a24 F src/whereInt.h 6804c2e5010378568c2bb1350477537755296a46 F test/8_3_names.test ebbb5cd36741350040fd28b432ceadf495be25b2 F test/aggerror.test a867e273ef9e3d7919f03ef4f0e8c0d2767944f2 @@ -407,7 +407,7 @@ F test/corruptF.test be9fde98e4c93648f1ba52b74e5318edc8f59fe4 F test/corruptG.test 1ab3bf97ee7bdba70e0ff3ba2320657df55d1804 F test/corruptH.test 88ed71a086e13591c917aac6de32750e7c7281cb F test/corruptI.test b3e4203d420490fc3d3062711597bc1dea06a789 -F test/cost.test 3f7904d623ef8dc6e55f2206db5ce0549077b438 +F test/cost.test 04842adec34311d70c3f3c5fd698b22be54138fd F test/count.test 42a251178e32f617eda33f76236a7f79825a50b5 F test/coveridxscan.test cdb47d01acc4a634a34fd25abe85189e0d0f1e62 F test/crash.test fb9dc4a02dcba30d4aa5c2c226f98b220b2b959f @@ -1166,7 +1166,7 @@ F tool/vdbe_profile.tcl 67746953071a9f8f2f668b73fe899074e2c6d8c1 F tool/warnings-clang.sh f6aa929dc20ef1f856af04a730772f59283631d4 F tool/warnings.sh d1a6de74685f360ab718efda6265994b99bbea01 F tool/win/sqlite.vsix 030f3eeaf2cb811a3692ab9c14d021a75ce41fff -P af2cbe64adab5f9e3b0f3da00d06428088589d7f 05e6e16cb28c9ffb4596bd2ef81f687c5403ecbb -R 20e49e26218874ddfe5fb9438df8f580 +P 90e36676476e8db00658772e6c938242f766d306 +R cf0f5a4a25fa17ee63b35d342904cb95 U dan -Z 75da520dd73c7e9f7e5ee96ec52c5c59 +Z 15897e765882c5d27e5f655ffd8d3c94 diff --git a/manifest.uuid b/manifest.uuid index 437f1a2753..274547b53f 100644 --- a/manifest.uuid +++ b/manifest.uuid @@ -1 +1 @@ -90e36676476e8db00658772e6c938242f766d306 \ No newline at end of file +9bbca48b42e4fe16f2188e18dc736da30a96435c \ No newline at end of file diff --git a/src/where.c b/src/where.c index 7d01db61ee..3b96e5fbea 100644 --- a/src/where.c +++ b/src/where.c @@ -4738,7 +4738,7 @@ static int whereLoopAddOr(WhereLoopBuilder *pBuilder, Bitmask mExtra){ int iCur; WhereClause tempWC; WhereLoopBuilder sSubBuild; - WhereOrSet sSum, sCur, sPrev; + WhereOrSet sSum, sCur; struct SrcList_item *pItem; pWC = pBuilder->pWC; @@ -4794,6 +4794,7 @@ static int whereLoopAddOr(WhereLoopBuilder *pBuilder, Bitmask mExtra){ whereOrMove(&sSum, &sCur); once = 0; }else{ + WhereOrSet sPrev; whereOrMove(&sPrev, &sSum); sSum.n = 0; for(i=0; iiSortIdx = 0; memset(&pNew->u, 0, sizeof(pNew->u)); for(i=0; rc==SQLITE_OK && irRun = sSum.a[i].rRun; + /* TUNING: Currently sSum.a[i].rRun is set to the sum of the costs + ** of all sub-scans required by the OR-scan. However, due to rounding + ** errors, it may be that the cost of the OR-scan is equal to its + ** most expensive sub-scan. Add the smallest possible penalty + ** (equivalent to multiplying the cost by 1.07) to ensure that + ** this does not happen. Otherwise, for WHERE clauses such as the + ** following where there is an index on "y": + ** + ** WHERE likelihood(x=?, 0.99) OR y=? + ** + ** the planner may elect to "OR" together a full-table scan and an + ** index lookup. And other similarly odd results. */ + pNew->rRun = sSum.a[i].rRun + 1; pNew->nOut = sSum.a[i].nOut; pNew->prereq = sSum.a[i].prereq; rc = whereLoopInsert(pBuilder, pNew); diff --git a/test/cost.test b/test/cost.test index 045a4c08d6..c413c3cdfa 100644 --- a/test/cost.test +++ b/test/cost.test @@ -150,7 +150,6 @@ do_eqp_test 7.2 { 0 0 0 {USE TEMP B-TREE FOR ORDER BY} } -#set sqlite_where_trace 0xfff do_eqp_test 7.3 { SELECT rowid FROM t1 WHERE (+b IS NULL AND c NOT NULL AND d NOT NULL) @@ -160,6 +159,12 @@ do_eqp_test 7.3 { 0 0 0 {SCAN TABLE t1} } +do_eqp_test 7.4 { + SELECT rowid FROM t1 WHERE (+b IS NULL AND c NOT NULL) OR c IS NULL +} { + 0 0 0 {SCAN TABLE t1} +} + #------------------------------------------------------------------------- # reset_db