Fix a couple of out-of-date comments in where.c.

FossilOrigin-Name: eefeda32d54efbbdf7d20b719299eda48b891fae

diff --git a/manifest b/manifest
index 29bd3a7832d6c86057352ec3b0c2d718c2c2fa66..8167b75420d48fc258890ee74cc367cf633e07ea 100644 (file)
--- a/manifest
+++ b/manifest
@@ -1,5 +1,5 @@
-C Improved\srendering\sof\sLogEst\svalues\scorresponding\sto\sreal\svalues\snear\s0.0\nin\sthe\stool/logest.c\sutility\sprogram.
-D 2014-04-30T14:22:38.579
+C Fix\sa\scouple\sof\sout-of-date\scomments\sin\swhere.c.
+D 2014-04-30T14:47:01.628
 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 9651faf05f900d9235bf3166fa54a9e5f12a40f2
+F src/where.c e91b92908c973b2b6b03145dcd131a8ca8b1bf64
 F src/whereInt.h 6804c2e5010378568c2bb1350477537755296a46
 F test/8_3_names.test ebbb5cd36741350040fd28b432ceadf495be25b2
 F test/aggerror.test a867e273ef9e3d7919f03ef4f0e8c0d2767944f2
@@ -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 b9f91317c34d07769a95dc2f905a6ccabceb64a3
-R 0e5a317f465f102c0002288cd477a07d
-U drh
-Z 88c640e8cc6f42fa637c9ebb251cd8ac
+P 32910c8c595858245bb7ecfe3aa0f90eeae641af
+R 26fff8d56fc56eff56bc1e57cba958ab
+U dan
+Z b9aa63fbb519903c6b0c5b0a6a8e051f

diff --git a/manifest.uuid b/manifest.uuid
index 7421cca676c52db837a89528941035fe74313bfd..6c9c8ac5b7753433440bdcac2cb2df96e144594b 100644 (file)
--- a/manifest.uuid
+++ b/manifest.uuid
@@ -1 +1 @@
-32910c8c595858245bb7ecfe3aa0f90eeae641af
\ No newline at end of file
+eefeda32d54efbbdf7d20b719299eda48b891fae
\ No newline at end of file

diff --git a/src/where.c b/src/where.c
index aea0be3042bc96470dc67a665040082a10d8595d..ec7a908b1a24e6059291eb77d7edfdb05c7b2f75 100644 (file)
--- a/src/where.c
+++ b/src/where.c
@@ -4022,8 +4022,13 @@ static void whereLoopOutputAdjust(WhereClause *pWC, WhereLoop *pLoop){
 }
 
 /*
-** We have so far matched pBuilder->pNew->u.btree.nEq terms of the index pIndex.
-** Try to match one more.
+** We have so far matched pBuilder->pNew->u.btree.nEq terms of the 
+** index pIndex. Try to match one more.
+**
+** When this function is called, pBuilder->pNew->nOut contains the 
+** number of rows expected to be visited by filtering using the nEq 
+** terms only. If it is modified, this value is restored before this 
+** function returns.
 **
 ** If pProbe->tnum==0, that means pIndex is a fake index used for the
 ** INTEGER PRIMARY KEY.
@@ -4085,10 +4090,14 @@ static int whereLoopAddBtreeIndex(
 
   /* Consider using a skip-scan if there are no WHERE clause constraints
   ** available for the left-most terms of the index, and if the average
-  ** number of repeats in the left-most terms is at least 18.  The magic
-  ** number 18 was found by experimentation to be the payoff point where
-  ** skip-scan become faster than a full-scan.
-  */
+  ** number of repeats in the left-most terms is at least 18. 
+  **
+  ** The magic number 18 is selected on the basis that scanning 17 rows
+  ** is almost always quicker than an index seek (even though if the index
+  ** contains fewer than 2^17 rows we assume otherwise in other parts of
+  ** the code). And, even if it is not, it should not be too much slower. 
+  ** On the other hand, the extra seeks could end up being significantly
+  ** more expensive.  */
   assert( 42==sqlite3LogEst(18) );
   if( pTerm==0
    && saved_nEq==saved_nSkip
@@ -5226,23 +5235,27 @@ static int wherePathSolver(WhereInfo *pWInfo, LogEst nRowEst){
                        pWInfo->pOrderBy, pFrom, pWInfo->wctrlFlags,
                        iLoop, pWLoop, &revMask);
           if( isOrdered>=0 && isOrdered<nOrderBy ){
-            /* TUNING: Estimated cost of sorting is N*log(N).
-            ** If the order-by clause has X terms but only the last Y terms
-            ** are out of order, then block-sorting will reduce the sorting
-            ** cost to N*log(N)*log(Y/X).  The log(Y/X) term is computed
-            ** by rScale.
-            ** TODO: Should the sorting cost get a small multiplier to help
-            ** discourage the use of sorting and encourage the use of index
-            ** scans instead?
-            */
+            /* TUNING: Estimated cost of a full external sort, where N is 
+            ** the number of rows to sort is:
+            **
+            **   cost = (3.0 * N * log(N)).
+            ** 
+            ** Or, if the order-by clause has X terms but only the last Y 
+            ** terms are out of order, then block-sorting will reduce the 
+            ** sorting cost to:
+            **
+            **   cost = (3.0 * N * log(N)) * (Y/X)
+            **
+            ** The (Y/X) term is implemented using stack variable rScale
+            ** below.  */
             LogEst rScale, rSortCost;
             assert( nOrderBy>0 && 66==sqlite3LogEst(100) );
             rScale = sqlite3LogEst((nOrderBy-isOrdered)*100/nOrderBy) - 66;
             rSortCost = nRowEst + estLog(nRowEst) + rScale + 16;
 
             /* TUNING: The cost of implementing DISTINCT using a B-TREE is
-            ** also N*log(N) but it has a larger constant of proportionality.
-            ** Multiply by 3.0. */
+            ** similar but with a larger constant of proportionality. 
+            ** Multiply by an additional factor of 3.0.  */
             if( pWInfo->wctrlFlags & WHERE_WANT_DISTINCT ){
               rSortCost += 16;
             }