बैच दो अनुवाद लुकअप प्लानर प्रति पंक्ति बुरी तरह से कर रहा था

शिप

23 सितंबर 2026 को 1:37 pm बजे UTC

लेखक

Kamo

Commit

cf061b2

kbservice के सार्वजनिक KB समापन बिंदु और इसके अनुवाद-retry स्वीप दोनों ने पूछा KbArticletranslationRepository एक समय में एक पंक्ति। उत्पादन pg stat statementments ने उस से दो बहुत अलग लागत दिखायी: - findRealtranslationLocales (new): साइटमैप / hreflang लुकअप को पीछे छोड़ देता है कि अनुवाद सेवा की अंग्रेजी-फॉलबैक पंक्तियों से वास्तविक अनुवाद बताता है (एक पंक्ति अंग्रेजी को स्थानीय कुंजी के तहत रख सकती है जब कोई प्रदाता मौजूद नहीं है वह दिशा है। इस क्लस्टर की योजना YugabyteDB की विरासत heuristic के साथ है मॉडल (कोई अनुकूलक आंकड़े नहीं) और JPQL के लिए एक नेस्टेड लूप का चयन किया kb article translations से kb articles में शामिल हों: एक इंडेक्स स्कैन यूआईडी सूची, फिर kb articles में एक अलग एकल-पंक्ति सूचकांक लुकअप उन पंक्तियों में से प्रत्येक - 6,468 भंडारण RPCs एक 308-article org के लिए, 11.9 s, दो तालिकाओं में शामिल होने के लिए जो स्मृति में एक साथ फिट होते हैं (~6,000 कॉल) प्रत्येक उत्पादन में ~ 11 s। एक pg hint plan HashJoin संकेत के साथ मूल SQL इसके बजाय जुड़ना ************* EXPLAIN के साथ सत्यापित उत्पादन: 11.9 s -> 0.2 s, नीचे स्थिर plan cache mode = force generic plan (आकार JDBC सर्वर साइड) वास्तव में नीचे चलाने के लिए तैयार है). - countgroupedbyArticleUid (new): दस मिनट का अनुवाद-retry स्वीप कहा जाता है countbyArticle Uid एक बार प्रति प्रकाशित लेख खोजने के लिए कौन से लोगों को अभी भी स्थानीय लोगों की जरूरत है - उत्पादन में 1.7M कॉल, प्रत्येक उप-millisecond अकेले। पूरे बैच में एक समूहीकृत काउंटी एक ही उत्तर है; एक uid परिणाम से अनुपस्थित शून्य पंक्तियां हैं। kbservice तारों इन दोनों में (अलग-अलग प्रतिबद्ध, अपनी खुद की रेपो)।.