Draft: batch catalog extraction for single-connection performance#188
Draft
Draft: batch catalog extraction for single-connection performance#188
Conversation
|
Copilot
AI
changed the title
[WIP] Improve performance for extract catalog using single SQL query
Draft: batch catalog extraction for single-connection performance
Apr 11, 2026
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
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.
This work targets the single-connection catalog extraction path, where many small metadata queries add avoidable round trips and latency. The intended change is to keep the extraction code modular while allowing the catalog data to be fetched through one batched SQL execution, with timing coverage to compare both approaches.
Performance coverage
Catalog extraction path
extractCatalogthat runs one large SQL request instead of issuing many independent catalog queries.Behavioral compatibility
Catalogshape and normalization flow unchanged so downstream diff/planning code continues to consume the same model.