perf: skip redundant sessions query for file-only search (CS-32)#112
Merged
Conversation
searchIndexedSessions ran searchSessions unconditionally next to the file-activity path, and for file-only queries its hits were always dropped by the first-write-wins dedupe. Skip it when nothing else can contribute: no text, no tools (empty-query branch is their sole source), no tags (the file path is tag-blind), and no from/to window (the file path filters on fa.latest_time, not activity_time).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
searchIndexedSessionsalways ransearchSessionsalongside the file-activity path; for file-only queries every one of its hits was dropped by the first-write-wins dedupe — one wasted SQL round-trip per search (found during CS-30 characterization, quirk #7).The skip is deliberately narrow.
searchSessionsstill runs whenever it can contribute:listFileActivityhas no tag clause, so tag filtering only happens insearchSessionsfa.latest_time, not the session'sactivity_timesearchFileActivitySessionsreturns nothing without a path, sosearchSessionsis the only sourceNew outcome tests assert each boundary via a
Database.prototype.preparespy (the sessions-table query is provably absent for file-only, provably present for the other four cases). The file+tags test also pins a pre-existing quirk as-is: file-path hits are tag-blind and win the dedupe, so a mismatched-tag session still surfaces today — unchanged by this PR, documented in the issue notes.Verification
pnpm build✓,pnpm test✓ (core 291 / web 228 / cli 105),pnpm test:e2e✓Issue: CS-32