SQLite

Timeline
Login

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

18 check-ins related to "in-scan-vs-index"

2020-09-30
18:06
Improved query optimization for multi-column indexes where the second or later columns are constrained by an IN operator and the earlier index columns limit the search to a small number of rows. Use the new OP_SeekScan opcode which does scanning of the relevant range of the index but gives up and falls back to doing a seek if the number of rows scanned grows to large, in order to guard against pathological cases where the estimated number of rows to be scanned is far too small. (check-in: 4a43430f user: drh tags: trunk)
18:03
For the OP_SeekScan opcode, adjust the number of steps run before giving up based on the estimated number of comparisons needed to perform a seek. (Closed-Leaf check-in: dc4172e6 user: drh tags: in-scan-vs-index)
00:48
Add an sqlite3FaultSim() call to btreeNext() to make it easier to simulate I/O errors in calls to sqlite3BtreeNext(), and in OP_SeekScan. (check-in: 29cca775 user: drh tags: in-scan-vs-index)
00:10
In the OP_SeekScan opcode, changes to pOp must occur after the call to VdbeBranchTaken() so that the VdbeBranchTaken() attributes the branch to the correct opcode. (check-in: 61fbe7aa user: drh tags: in-scan-vs-index)
2020-09-29
23:52
The OP_SeekScan opcode is a no-op if the cursor is not pointing to a valid row upon entry. (check-in: 4afc96b5 user: drh tags: in-scan-vs-index)
20:22
Coverage testing of the OP_SeekScan opcode. Fix a problem that comes up when OP_SeekScan reaches the end of the table. (check-in: 9e57e758 user: drh tags: in-scan-vs-index)
17:29
Improved comments on the new OP_SeekScan opcode. (check-in: 6110fdd5 user: drh tags: in-scan-vs-index)
16:05
Improved performance by manually in-lining the sqlite3VdbeIdxKeyCompare() routine for the OP_IdxGT opcode and its kin. (check-in: 2206a2c8 user: drh tags: in-scan-vs-index)
15:32
Typo fix to repair the early-out optimization. Also avoid unnecessary OP_SeekHit opcodes. (check-in: 8fd7d8df user: drh tags: in-scan-vs-index)
01:48
The OP_SeekScan opcode works, but using it requires disabling the IN-earlyout optimization because the OP_IfNoHope opcode might move the cursor. (check-in: f3c36b84 user: drh tags: in-scan-vs-index)
2020-09-28
19:51
Revisiting the IN-scan optimization to try to fix it for the corner case where the statistics deceive the query planner into using a scan when an indexed lookup would be better. This check-in changes the code generation to do the IN-scan using a new OP_SeekScan opcode. That new opcode is designed to abandon the scan and fall back to a seek if it doesn't find a match quickly enough. For this work-in-progress check-in, OP_SeekScan is still a no-op and OP_SeekGE still ends up doing all the work. (check-in: d720b698 user: drh tags: in-scan-vs-index)
15:49
Small performance improvement and size reduction by reducing the size of the WhereTerm object. (check-in: 43f7ddad user: drh tags: trunk)
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)
19:13
Fix an assert() that can be false for a corrupt database and a strange query that uses a recursive SQL function to delete content from a corrupt database file while it is being queried. (check-in: 99057383 user: drh tags: trunk)
18:22
Consider doing a partial table scan to fulfill an IN operator rather than using an index. Try to pick the plan with the lowest cost. (check-in: 1fa40a78 user: drh tags: in-scan-vs-index)
2018-06-07
18:13
The IN-early-out optimization: When doing a look-up on a multi-column index and an IN operator is used on a column other than the left-most column, then if no rows match against the first IN value, check to make sure there exist rows that match the columns to the right before continuing with the next IN value. (check-in: 09fffbdf user: drh tags: trunk)