- Порезанный
- 23 сентября 2026 г. в 13:37 UTC
- Автор
- Kamo
- Обещать
- cf061b2
публичные конечные точки KB сервиса kbservice и его переводо-ретритная разметка оба запросили KbArticleTranslationРепозиторий один ряд за раз. Производство pg stat statements показал две очень отличающиеся друг от друга затраты: - findRealTranslationLocales (новый): поддерживает поиск по карте сайта / hreflang, который Рассказывает реальный перевод с англоязычных обратных рядов TranslateService (Строка может содержать английский язык под локальным ключом, когда не существует провайдера). в этом направлении. Этот кластер планирует с наследием YugabyteDB Модель (без статистики оптимизатора) и выбранная конфигурация для JPQL kb article translations to kb articles: индексное сканирование uid list, затем отдельный однорядный индекс поиска в kb articles каждый из этих рядов — 6468 накопителей RPC для 308-частичного узла; 11,9 с, чтобы соединить две таблицы, которые вместе помещаются в память (~ 6000 вызовов). - по 11 штук на производстве. Нативный SQL с подсказкой pg hint plan Вместо этого подключает соединение (та же техника, что и **************************** Проверено с объяснением на производство: 11,9 с -> 0,2 с, стабильно при plan cache mode = force generic plan (форма серверной стороны JDBC) На самом деле подготавливается. CountGroupedByArticleUid (новый): десятиминутный перевод-ретрит попросила CountByArticle Uid один раз за опубликованную статью найти, какие из них все еще нужны места — 1,7 млн звонков в производство, каждая субмиллисекунда наедине. Один сгруппированный счет по всей партии - тот же ответ; Отсутствие результата имеет нулевые ряды. kbservice проводов обоих из них в (отдельный фикс, собственный репо).