- Shipped
- September 23, 2026 at 1:39 PM UTC
- Author
- Kamo
- Commit
- 60e1921
Three queries pg_stat_statements showed as kbservice's top production DB cost, all from asking in a loop (or with a plan the legacy YugabyteDB planner picked badly) what a single query could answer: - **************** (the sitemap and every public tree/list/single-article response's hreflang data) now reads through **************** a pg_hint_plan-hinted native query (kamo-shared-library, separate commit) that pins a Hash Join the planner wasn't choosing on its own. ~6,000 calls at ~11 s each in production; verified with EXPLAIN, 11.9 s -> 0.2 s for the same 308-article org. - **************** (the ten-minute translation-retry sweep) now asks **************** once for the whole batch of published articles instead of countByArticle_Uid per article — 1.7M calls in production, replaced with one grouped read. - buildPublicChildrenMap and buildUidToGuidMap, in KbArticleService, are removed. They were dead code left behind when **************** moved to taking a pre-built PublicTreeIndex (155e7de) instead of rebuilding one from a full-row article load: neither had a caller left, but each was still exactly the ~306,000-call / ~80 ms full-row kb_articles query (content_json included) pg_stat_statements showed — a slow, unreachable trap for the next caller to find by using it, not live traffic. buildPublicTreeIndex itself already reads the narrow projection loadPublicArticlesForTree added in 155e7de, confirmed live in production (8,730 calls at ~17 ms each, growing) — that fix already shipped; this just removes the two leftover call sites still capable of reintroducing the full-row cost. Tests: KbTranslatedLocalesServiceTest and **************** cover the batching this adds (BATCH chunking, null/duplicate uid handling, grouped-row mapping, "absent means zero"); both mutation-checked by reverting the fix locally, confirming they go red, and restoring it. Also reviewed: kb_article_relations and the paginated KB-admin listing queries (org/status/parent_id variants of the kb_articles full-row load) appear in pg_stat_statements with large totals but unremarkable per-call latency (1-20 ms) and no sign of a bad plan — left alone. **************** is called once per item on the public children-by-parent-slug page (bounded by page size, gated behind non-English locale) — not the runaway pattern the other three were, so also left alone.