Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Parents and children of check-in [99057383]
|
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) | |
| 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) | |
|
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) | |