- Verschifft
- 23. September 2026 um 13:37 UTC
- Autor
- Kamo
- Ausschuss
- cf061b2
kbservices öffentliche KB-Endpunkte und sein Übersetzungs-Retschrank Sweep fragten beide KbArticleTranspository eine Reihe nach der anderen. Produktion pg_stat_statements zeigten zwei sehr unterschiedliche Kosten: - findRealTranslationLocales (neu): rückt die Sitemap/hreflangen Suche nach erzählt eine echte Übersetzung aus den Englisch-Fallback-Reihen von TranslateService (eine Zeile kann Englisch unter einem Locale-Schlüssel halten, wenn kein Anbieter für diese Richtung). Dieses Cluster plant mit YugabyteDBs Vermächtnis heuristisch Modell (keine Optimierungsstatistik) und wählte eine Nested Loop für die JPQL verbinden von kb_article_translations zu kb_articles: ein Index-Scan für die uid Liste, dann eine separate Single-Rile-Index-Suche in kb_articles für jede dieser Zeilen - 6.468 Speicher-RPCs für einen 308-Artikel-Org, 11,9 s, um zwei Tabellen, die zusammen in Speicher passen (6.000 Anrufe an Jeweils 11 € in Produktion). Native SQL mit einem pg_hint_plan HashJoin Hinweis pins die verbinden statt (gleiche Technik wie **************** Verifiziert mit EXPLAIN auf Produktion: 11,9 s - 0,2 s, stabil unter plan_cache_mode = force_generic_plan (die Form JDBCs Server-Seite Vorbereitungen laufen tatsächlich unter). - countGroupedByArticleUid (neu): der zehnminütige Übersetzungs-Retry-Sweep gefragt GrafByArticle_Uid einmal pro veröffentlichtem Artikel zu finden, welche noch brauchen Locales 1,7M Anrufe in der Produktion, jede Sub-Millisekunde allein. Ein gruppierter COUNT über die ganze Charge ist die gleiche Antwort; ein uid Abwesend vom Ergebnis hat null Zeilen. kbservice wires beide in (separate Commit, seine eigene Repo).