Commit Graph

5 Commits

Author SHA1 Message Date
drh
cdfb518f6f Fix Bloom filters on an expression index.
[forum:/forumpost/2e427099d5|forum post 2e427099d5] and
[forum:/forumpost/d47a0e8e3a|forum post d47a0e8e3a].

FossilOrigin-Name: c028fb669a5ae34dbaf50fffab1ae49bc568b994435cf02e145d24da3cfb48d7
2023-03-14 20:08:39 +00:00
drh
4990fc84f1 Only use a Bloom filter on an automatic index if one or more of the key
columns in the index can take on non-TEXT values.

FossilOrigin-Name: 5916705c731604d2e6b51a307cc8d7b67f4c102062bfdfcbc716a2916e0b0d86
2023-02-28 18:06:52 +00:00
drh
a353369f57 In the Bloom filter optimization, hash all strings and blobs into the same
value, because we do not know if two different strings might compare equal
even if they have different byte sequences, due to collating functions.
Formerly, the hash of a string or blob was just its length.  This could
all be improved.  Fix for the issue reported by
[forum:/forumpost/0846211821|forum post 0846211821].

FossilOrigin-Name: 090304b870419acb5b05205a07fc75830b556928149f76a843cda526f77a6fc0
2023-02-28 14:28:54 +00:00
drh
072f48e556 Do not use a Bloom filter if any outer loop lacks STAT1 data, since without
STAT1 data, the query planner cannot make an accurate determination of
whether or not a Bloom filter will be useful.  This fixes the problem
reported by [forum:/forumpost/56de336385|forum post 56de336385].

FossilOrigin-Name: e6ab96bd0b9efc51fd703bf7e92b079943ad9a3b92183d434adc11fb7d238afb
2023-02-05 20:29:10 +00:00
dan
73ac958c74 Fix a problem that occurred when using a bloom filter to optimize an (ipk = ?) lookup in the case where the RHS of the expression is a TEXT value. First reported by [forum:/forumpost/f61a8b7053|forum post f61a8b7053].
FossilOrigin-Name: 8e14c351b29bb434ac4e2510681e95716424a73e340d39feff4919f0431c2e00
2022-10-06 14:10:11 +00:00