]> git.ipfire.org Git - thirdparty/sqlite.git/commit
When the query planner has the opportunity to use an IN operater constraint
authordrh <drh@noemail.net>
Fri, 8 Jun 2018 23:23:53 +0000 (23:23 +0000)
committerdrh <drh@noemail.net>
Fri, 8 Jun 2018 23:23:53 +0000 (23:23 +0000)
commit7128b7c1f4036a76f74375be67d9837b7c0705cb
treedd14161f65b9b1b87e9e878b3e1705bd3bb5d7c1
parentf3cd0c82dfc744e446203c89c7152380f85da5d5
parent6d6decb8d92ea6422f301ffa6dfbb1015aec8110
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 looks, 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.

FossilOrigin-Name: 2cbbabdf5ef624d809fbb40d2d312a29e0b5f02756fc0dbf6985fc8b0c8d1ade
manifest
manifest.uuid