Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.
|Comment:||Only choose to scan an IN operator rather than use an index if we have real STAT1 data to suggest it is advantageous.|
|Downloads:||Tarball | ZIP archive | SQL archive|
|Timelines:||family | ancestors | descendants | both | in-scan-vs-index|
|Files:||files | file ages | folders|
|User & Date:||drh 2018-06-08 21:21:01|
|23:23||When the query planner has the opportunity to use an IN operater constraint on a term of an index other than the left-most term, use the estimated number of elements on the right-hand side of the IN operator to determine if makes sense to use the IN operator with index lookups, or to just do a scan over the range of the table identified by the index terms to the left. Only do this if sqlite_stat1 measurements are available as otherwise the performance estimates will not be accurate enough to discern the best plan. Bias the decision slightly in favor of using index lookups on each element of the IN operator. (check-in: 2cbbabdf user: drh tags: trunk)|
|21:21||Only choose to scan an IN operator rather than use an index if we have real STAT1 data to suggest it is advantageous. (Closed-Leaf check-in: 30e87466 user: drh tags: in-scan-vs-index)|
|19:54||Merge the btreeNext() assertion bug fix from trunk. (check-in: 11bd66e0 user: drh tags: in-scan-vs-index)|
Changes to src/where.c.
Changes to test/in6.test.
Changes to test/rowvalue4.test.