/ Check-in [30e87466]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
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
SHA3-256: 30e874661dcc1a2ecb40df2ef74582151d85bb36c754a38548829a3b6285f18d
User & Date: drh 2018-06-08 21:21:01
Context
2018-06-08
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
Unified Diffs Side-by-Side Diffs Patch

Changes to src/where.c.

Changes to test/in6.test.

Changes to test/rowvalue4.test.