Conversation
- Replaced inefficient O(N^2) manual offset pagination loop with a single query execution. - Fixed a bug where `order_by` was ignored because the result was not assigned. - This improves performance for fetching knowledge bases, especially when the count is large. Co-authored-by: nkissick-del <236767245+nkissick-del@users.noreply.github.com>
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
⚡ Bolt: Optimize Knowledgebase Fetch
💡 What:
Replaced the manual offset/limit loop in
KnowledgebaseService.get_all_kb_by_tenant_idswith a single query execution. Also fixed a bug whereorder_bywas ignored.🎯 Why:
The original implementation used a
whileloop withoffsetandlimitto fetch all records. This causes N/batch_size queries, and each query gets slower due toOFFSETscanning (O(N^2) total work). It also had a bug wherekbs.order_by(...)was called without assignment, so the results were likely unordered.📊 Impact:
🔬 Measurement:
Verified with a unit test (
test/unit_test/services/test_kb_perf.py) which mocked the DB and asserted thatoffsetandlimitare no longer called, and thatdicts()is called on the ordered query object. The test was deleted after verification.PR created automatically by Jules for task 8961361476201916237 started by @nkissick-del