fix: fast_search limits full text search to indexed fragments#6006
fix: fast_search limits full text search to indexed fragments#6006
Conversation
|
ACTION NEEDED The PR title and description are used as the merge commit message. Please update your PR title and description to match the specification. For details on the error please inspect the "PR Title Check" action. |
BubbleCal
changed the title
Code ReviewSummary: This PR correctly implements AssessmentThe implementation is sound:
No P0/P1 Issues FoundThe code changes are well-scoped and follow the established patterns in the codebase. Minor Suggestion (non-blocking)The plan assertion test in the existing test case verifies the "mixed indexed/unindexed" scenario. Consider adding a plan assertion for the "no index at all + fast_search" path in a follow-up to ensure |
| if self.fast_search { | ||
| return Ok(Arc::new(EmptyExec::new(FTS_SCHEMA.clone()))); | ||
| } |
There was a problem hiding this comment.
This is slightly different from vector search. In vector search, if there is no index, then fast_search is just ignored (it still does an exhaustive KNN). However, I kind of like this behavior better. So I think I'm just pointing it out. We can update vector search later.
There was a problem hiding this comment.
ic, let me update the vector search behavior in next PR
…format#6006) Summary - short-circuit FTS scans when `fast_search` is enabled and no indexed fragments exist so we return an empty plan instead of scanning unindexed data - skip the unindexed-match planning path entirely under `fast_search`, forcing only index-backed queries even when fragments exist - add plan verification and a regression test proving `fast_search` excludes rows appended after building the FTS index
…format#6006) Summary - short-circuit FTS scans when `fast_search` is enabled and no indexed fragments exist so we return an empty plan instead of scanning unindexed data - skip the unindexed-match planning path entirely under `fast_search`, forcing only index-backed queries even when fragments exist - add plan verification and a regression test proving `fast_search` excludes rows appended after building the FTS index
Summary - short-circuit FTS scans when `fast_search` is enabled and no indexed fragments exist so we return an empty plan instead of scanning unindexed data - skip the unindexed-match planning path entirely under `fast_search`, forcing only index-backed queries even when fragments exist - add plan verification and a regression test proving `fast_search` excludes rows appended after building the FTS index
2 participants
Summary
fast_searchis enabled and no indexed fragments exist so we return an empty plan instead of scanning unindexed datafast_search, forcing only index-backed queries even when fragments existfast_searchexcludes rows appended after building the FTS index