Turned out hacks to avoid usage of vector indices in planner were not enough. Actually, bUnordered field set by sqlite3 during index analysis process and manipulating with it can be dangerous and error-prone (as sqlite3 can reset it at any moment).
So, this PR fixes this more robustly:
opMask is set to 0 for vector index in whereLoopAddBtreeIndex which must additionally prevent sqlite to use index in any operations (>, >=, =, IN) (actually, it shouldn't happen because index has expression - but still - this is another guard)
whereIsCoveringIndex return false for vector index
Loop over indices in query planner skips vector indices completely
All places where optimizer prevented to use bUnordered indices were extended to have additional check for idxIsVector field
Context
PR https://github.com/tursodatabase/libsql/pull/1594 tried to solve issue with sqlite planner using vector index for some optimizations (for example in
SELECT COUNT(*) FROM tqueries).Turned out hacks to avoid usage of vector indices in planner were not enough. Actually,
bUnorderedfield set bysqlite3during index analysis process and manipulating with it can be dangerous and error-prone (as sqlite3 can reset it at any moment).So, this PR fixes this more robustly:
opMaskis set to 0 for vector index inwhereLoopAddBtreeIndexwhich must additionally prevent sqlite to use index in any operations (>,>=,=,IN) (actually, it shouldn't happen because index has expression - but still - this is another guard)whereIsCoveringIndexreturn false for vector indexbUnorderedindices were extended to have additional check foridxIsVectorfield