Index the columns 'llm logs' looks rows up by, use 'union all' for the latest-conversation lookup - #1657
Open
rdslw wants to merge 1 commit into
Open
Index the columns 'llm logs' looks rows up by, use 'union all' for the latest-conversation lookup#1657rdslw wants to merge 1 commit into
rdslw wants to merge 1 commit into
Conversation
…ry conversation id for 'prompt -c' EXPLAIN QUERY PLAN over the queries llm logs issues showed five scans that grow linearly with the store. m028_log_lookup_indexes: - parts(type, tool_name, message_hash): the --tools/-T filters resolve "messages carrying a tool_result part (of this name)". That was a full scan of parts - the fastest-growing table - plus a transient automatic index SQLite built on every query. The trailing message_hash makes the index covering for exactly that subquery. - tool_calls/tool_results/tool_responses(response_id): the legacy extras and legacy --tools filter read these only through correlated subqueries on response_id - one full scan per listed response, and tool_results rows carry the tool outputs. tool_responses' primary key starts with tool_id, so it could not serve the probe either. - responses(conversation_id): --cid on the legacy side was a full responses scan; turns got idx_turns_thread_id in m023 but the legacy column never got the equivalent. load_conversation(): the latest-conversation lookup for 'prompt -c' used a distinct union of threads and conversations, which materializes every id from both tables before sorting for one row. 'union all' lets SQLite stop at the first row of each primary key; the outer limit 1 already discards any dual-write duplicate. tests/test_migrate.py asserts migrate() leaves all five indexes in place.
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.
EXPLAIN QUERY PLANover the queriesllm logsruns shows five lookups that scan a whole table. Fine at hundreds of rows, painful as the store grows. This adds one migration with five indexes and a one-word query change:parts(type, tool_name, message_hash)- the--tools/-Tfilters resolve "messages with a tool_result part" by scanningparts, the fastest-growing table, and building a transient automatic index on every query.tool_calls,tool_results,tool_responsesonresponse_id- the legacy extras and the legacy--toolsfilter probe these per listed response through correlated subqueries.responses(conversation_id)- legacy--cidfiltering;turns.thread_idgot its index in m023, this column never did.load_conversation()forprompt -cused a distinctunionofthreadsandconversations, which materializes every id before taking one row.union alllets SQLite stop at the first row of each primary key; the outerlimit 1already discards any dual-write duplicate.Measured on a copy of my logs.db (442 legacy responses, 359 turns, 1202 parts) and the same database replicated 50x (22k responses, 18k turns, 60k parts). Query timings, median of 15 runs:
--toolsfilter--cidfilter--toolsfilter (parts)-T namefilter (parts)prompt -c(12k threads)End to end at 50x, hyperfine mean of 3 runs (about 2 s of each is interpreter and plugin startup):
llm logs list --tools -n 5llm logs list -T Brave_context -n 5llm logs list --cid ID -n 5The five indexes add about 0.6% to the file size. If you prefer a smaller footprint on
parts, a partial indexon parts (tool_name, message_hash) where type = 'tool_result'serves the same query; happy to switch.Created with help of Fable-5.1 during migration of llm-openai-codex from llm-0.32 to llm-0.33.